Zero-Downtime Deployments: How We Ship to Production Without Breaking Client Sites

Across the products we run — our own and clients' — deploys happen multiple times a week, often to systems with live users mid-session. That only works if a bad deploy is rare and a rare bad deploy is invisible to whoever's using the product at that moment. Neither of those happens by accident; both come from a specific set of practices applied consistently.

The new version has to run before it takes traffic

The core discipline behind zero-downtime deploys is simple to state and easy to skip under time pressure: the new version of the app comes up, passes a real health check, and only then starts receiving traffic — while the old version keeps serving requests the entire time. A deploy that stops the old process before the new one is confirmed healthy is a guaranteed outage window, even if it's only a few seconds. A few seconds is still long enough to drop requests mid-transaction on a payment flow.

Database migrations are the part that actually breaks things

Application code swaps cleanly because old and new versions of a stateless process can run side by side for a moment. A database schema can't run two versions of itself at once — which is exactly why the migration, not the code deploy, is where most real production incidents come from. The rule we hold every migration to: it has to be backward-compatible with the version of the code still running during the rollout window. Renaming a column outright breaks the old code the instant the migration runs; adding a new column, deploying code that writes to both, and dropping the old column in a separate, later deploy doesn't.

Feature flags decouple "deployed" from "live"

Shipping code and turning a feature on for users are two different events, and conflating them is how a risky change ends up all-or-nothing at the exact moment it goes to production. A flag lets new code deploy dark, get verified against production traffic patterns with zero user-facing risk, and then get switched on for a small percentage first — the failure mode for a flagged rollout is "turn the flag back off," not "roll back a deploy."

Staging has to actually resemble production

A staging environment running a different database size, different traffic volume, or stale seed data catches a different, smaller set of bugs than production traffic will. It's not free to keep staging realistic — data needs periodic refreshing, load needs to be somewhat representative — but a staging pass that doesn't resemble production gives false confidence, which is worse than knowing you have no staging coverage at all.

Rollback has to be a decision, not a scramble

The deploy pipeline keeps the previous version's artifact ready to reinstate, and the decision to roll back is a single command, not a rebuild-and-redeploy-under-pressure exercise. The value of a fast rollback path isn't that it gets used often — it's that its existence changes how confidently the team can ship in the first place. A team that knows rollback takes twenty minutes ships more cautiously than one that knows it takes twenty seconds, and that caution shows up as slower iteration on every change, not just the risky ones.

Zero-downtime deployment isn't a tool you install. It's a set of constraints — backward-compatible migrations, health-checked traffic cutover, a real rollback path — applied to every single deploy, not just the ones that feel risky in advance.

If you're evaluating a development team's engineering maturity, ask how their last production incident actually got resolved — a team with a real rollback discipline describes a specific, boring procedure. A team without one describes a scramble.