> I would rather a system that holds requests for 20s max if the backend refuses connections. I think that's what nginx does by default, isn't it? Try again un

> I would rather a system that holds requests for 20s max if the backend refuses connections. I think that's what nginx does by default, isn't it? Try again until "gateway timeout". The problem in this case is if you want graceful shutdown you need your backend to stop accepting new connections without stopping to process the existing ones, then update the app. If some client connections are long-lived, that's a hard problem and that's why in that case running a second instance makes sense if you can do it. > Then every app consuming the API needs to be updated to support the 425 code gracefully. That's indeed a problem, but your client should probably support some forms of server "failure" modes, including a "try again soon" type of reply (or interpreting 5XX as such). > I have to manually do this switch in nginx before and after the update... This can be fully automated. Just use different config files in sites-enabled. Then you can mv or ln to enable one or the other and run nginx -s reload. The whole process would be a few lines of shell script.