Zero-Downtime Deploys & Rolling Updates

The plain-language idea

A rolling update replaces old containers with new ones incrementally — a few at a time, never all at once — so total capacity never drops to zero mid-deploy. That's the mechanism the orchestration-basics lesson in this track named as one piece of self-healing/scaling behavior. This lesson is about what "zero-downtime" actually depends on beyond that basic description, because the phrase gets treated as automatic when it isn't.

Two things have to be true for a rolling update to genuinely avoid downtime:

• New containers must pass a health check before old ones are removed. "Started" and "ready to serve traffic" are different states — a container can be running and still be mid-startup (loading config, warming a cache, connecting to a database pool). Removing an old, working replica the instant a new one merely starts can route real traffic into a container that isn't ready to handle it yet.
• Old containers need to shut down gracefully, not get killed instantly. This is the SIGTERM handling this track's init-systems lesson covered — an orchestrator sending a stop signal and immediately yanking the container mid-request drops whatever was in flight, rolling update or not. The rollout mechanism and the application's shutdown behavior are two separate requirements, and a rolling update only delivers on its promise when both are actually in place.

See it in a real thing: capacity through a rollout

Start: 2 old replicas serving traffic, 0 new. Capacity: 2.

BackNext

Picture 2 replicas serving traffic, rolling forward to a new image, one at a time: start 1 new replica → wait for its health check to pass → then, and only then, remove 1 old replica. Repeat for the second pair. At every point in that sequence there are at least 2 healthy replicas serving traffic — capacity never drops, but for a window in the middle, the old and new versions of the application are running and serving requests simultaneously. That overlap is not a bug to eliminate; it's the entire mechanism.

What people usually miss

Watch out

• Blue-green deployment is a real alternative, not an inferior version of rolling updates. Blue-green runs a full second environment (new version) alongside the old one, then switches traffic over instantly once it's verified — trading double the running cost during the switch for an instant, trivially-easy rollback (just switch traffic back), versus a rolling update's gradual, harder-to-instantly-reverse transition.
• Database migrations are the part rolling updates don't solve for free. Old and new application versions run simultaneously during a rollout, which means both versions of the code are hitting the same database schema at once — a breaking schema change deployed alongside application code needs to be backward-compatible with the version being phased out, or the old replicas start failing before they're even removed.
• A health check needs to actually verify readiness, not just process existence. A check that only confirms "the process is running" (not "the app can reach its database, its cache, its downstream dependencies") will happily route traffic to a replica that's up but functionally broken.
• Rollout speed and safety are a real, tunable tradeoff, not a fixed default. Replacing containers one at a time is cautious but slow for a large fleet; replacing many at once finishes faster but shrinks how many healthy replicas remain if something goes wrong mid-rollout — orchestrators expose this as a configurable "max unavailable" style setting for a reason.

Why this matters in interviews

"How would you deploy a new version of this service with zero downtime?" is a standard systems-adjacent question, and a strong answer names the actual mechanism (health-gated replacement, graceful shutdown) and the real alternative (blue-green, with its cost/rollback tradeoff) rather than just saying "rolling update" as if the phrase alone guarantees the outcome.