Downtime is a choice
Most deploy-time outages are self-inflicted: a rollout that swaps every pod at once, a migration that locks a table, a health check that lies. Zero-downtime is less about exotic tooling and more about removing those sharp edges one by one.
Our baseline is a rolling update with strict readiness and graceful shutdown, so traffic only ever reaches pods that are genuinely ready and drains cleanly from pods that are leaving.
Blue-green for risky releases
For changes we cannot easily reverse in place, we stand up a full green environment alongside blue, run smoke tests against it, then flip traffic at the load balancer. Rollback is a single switch back to blue.
Because both environments are real, we catch configuration and dependency issues before a single user is affected.
Canary with real signals
We route a small slice of production traffic to the new version and watch the metrics that actually matter — error rate, latency percentiles, saturation. If they hold, we ramp; if they drift, we roll back automatically.
Automation is key: a human reading dashboards at 2am is not a rollback strategy.
Make database changes safe
Schema changes are decoupled from code deploys and always backward compatible: expand, migrate, then contract in a later release. No deploy ever depends on a migration completing first.
Put together, these practices let us release continuously across regions without ever scheduling a maintenance window.