Shipping mid-conversation without dropping an answer

Releasing a web app usually means a short window where requests land on a process that is restarting. For a page, that is a blink. For a streamed answer, it is a truncated sentence and a lost reply.

Two slots

The application runs in two identical slots on different ports. Only one of them receives traffic at any moment. A release builds into the idle slot, starts it, and leaves the live one completely untouched.

Before anything is switched, the new slot has to answer a preflight: the build has to exist, the process has to come up, and the health check has to pass thirty times in a row. Only then is the upstream pointed at the new port and the configuration reloaded. In-flight answers on the old slot finish on the old slot.

Why not containers and an orchestrator

Because the failure modes we actually have are a bad build and a bad config, and both are caught by the same preflight regardless of how the process is packaged. A rollback here is a one-line change back to the previous port, which is faster to reason about at two in the morning than a rolling update.

The check that earns its place

A deploy that passes its health check and still cannot answer a question is a deploy that has lied to you. So the same canary that watches production watches the newly promoted slot: a real question, a real answer, every minute. If it goes quiet, the status page reports it before anybody has to write a support message.