[Skinney]

If I’m deploying a new version of my app, the typical managed solution will spawn a new server instance with that new version, and once a health check has succeeded a couple of times it will reroute trafic to this new instance and kill the old one.

Previously this would be problematic, as the new instance might miss changes made by the old server. Is this fixed by these new changes?

[gwking]

It seems to me that you need to think about your server as the production database, rather than a web server instance that can be trivially spawned by a management layer.

When I deploy a new version of my python/sqlite web app, I do not replace the whole machine. I just upgrade the python package and restart the systemd service.

If I wanted to reduce downtime I could probably figure out a transition using SO_REUSEPORT. During the transition the old and new processes would be using the db concurrently, so the app would have to respect that case. If part of the upgrade requires a db schema change then I’m not sure how you could avoid some downtime. But I don’t know if it is possible with traditional dbs either.

[maxmcd]

I don't think this is trivially fixed since you can still only have one writer that is holding the lease.

Your new service will come up, but it won't be able to get the write lease until the previous server shuts down. Now you have tools to detect this, stop one writer, and start the other, but the service will likely have to experience some kind of requests queueing or downtime.