Zero-Downtime Deployment: What Actually Happens Behind the Scenes?

Users don't see maintenance pages anymore because a precise orchestration runs behind the scenes during deployments.

The Core Idea: Never replace everything at once. Bring the new version up next to the old one, then shift traffic gradually.

3 Major Deployment Strategies

• Rolling: Replace instances a few at a time. Cost-effective, but old and new versions run concurrently for a period.
• Blue/Green: Run a full new environment (green) beside the existing one (blue), then flip traffic at the load balancer. Rollback is instant.
• Canary: Route 5% of live users to the new version, monitor telemetry, and expand if healthy.

The Load Balancer Sequence

1. A new application instance boots up.
2. The load balancer waits for health checks to pass before routing traffic.
3. Traffic shifts to the new instance.
4. The old instance enters a draining state—stopping new requests while letting in-flight requests complete.
5. Once connections drain, the old instance shuts down gracefully.

Where Zero-Downtime Breaks

• Database schema changes: Since old and new versions run concurrently, database changes must be backward-compatible. Use the expand/contract pattern: add new columns first, deploy code using them, and remove old columns in a subsequent release.
• Lack of graceful shutdown: If app containers don't handle `SIGTERM`, active user requests get abruptly terminated.
• In-memory sessions: Server-side session state logs users out when an instance dies. Store sessions in Redis or DB.

Zero downtime is an architectural property of your application, not just a configuration in your CI/CD tool.

Which strategy does your team use?