Zero-downtime deploy

A zero-downtime deploy replaces the running version without users noticing: nobody sees 'be right back', nobody gets a 502. Treat it as a target you engineer toward rather than a box you tick, because no traffic-switching strategy delivers it on its own. The shape is always the same: bring new instances up, prove they are healthy, shift traffic to them, then drain and retire the old ones. Blue-green flips all traffic at once between two full environments; rolling replaces instances a few at a time; canary shifts a small percentage first.

Three pieces make it actually work. A health check endpoint the load balancer polls, so traffic only arrives once the new instance can serve it. Connection draining, a grace period where the old instance finishes in-flight requests but accepts no new ones. And graceful shutdown: catching SIGTERM, closing the server, letting background jobs finish instead of dying mid-write. Most managed platforms give you the first two; the third is your code's job. Blue-green will happily flip traffic away from instances still holding open websockets, so 'we do blue-green' is not an answer to 'what happens to in-flight connections'.

The misconception worth killing: zero downtime is mostly a data problem, not an infrastructure one. During the switch, old and new code run at the same time against one database, one cache, one queue. A destructive migration, a changed cache key format, or a job payload shape that only the new version understands will cause errors even though no instance ever went down. Every change has to work in both directions for the length of the rollout, and long-running requests or open websockets need a drain window generous enough to finish.