Swe Zero Downtime Deployment Blue Green

Zero-downtime deployment questions show up constantly in senior backend and infrastructure interviews in 2026 because they test something narrower and more valuable than “do you know the term blue-green” — they test whether you understand the actual failure modes around database schema changes, connection draining, and in-flight request handling that make deployments break in production despite “zero downtime” tooling being in place.

This article covers the mechanics interviewers actually probe, not the marketing-diagram version.

Blue-Green vs Canary vs Rolling: The Real Differences

The three dominant strategies get conflated constantly. The precise distinctions:

• Blue-green: two complete, identical production environments. Traffic cuts over atomically (via load balancer or DNS) from blue (old) to green (new). Rollback is instant — flip traffic back.
• Canary: a small percentage of traffic (often 1-5%) is routed to the new version while the rest stays on the old version, with gradual ramp-up based on error-rate/latency monitoring.
• Rolling deployment: instances are replaced incrementally, one batch at a time, with no full second environment — the default behavior of a Kubernetes Deployment object.

The key interview insight: these aren’t mutually exclusive. Production-grade pipelines in 2026 typically layer canary analysis (automated, metric-gated) on top of a blue-green cutover, using canary to validate the green environment with a small traffic slice before the full atomic switch.

Comparison Table

Notice the database compatibility row is identical across every zero-downtime strategy — this is the detail most candidates miss. Zero-downtime deployment isn’t primarily a deployment-tooling problem; it’s a schema and API compatibility problem that deployment tooling merely exposes.

The Database Migration Problem (Where Most “Zero Downtime” Claims Break)

The most common production incident behind a failed “zero-downtime” deploy isn’t the traffic cutover — it’s a database migration that isn’t backward compatible. The standard failure: a migration drops or renames a column while old-version pods are still serving traffic and querying that column.

The fix is the expand-contract pattern (also called parallel change):

1. Expand: add the new column/table alongside the old one. Deploy this migration first, independent of any app code change. Old code ignores the new column; nothing breaks.
2. Migrate + dual-write: deploy application code that writes to both old and new columns, and backfill existing rows.
3. Contract-read cutover: deploy application code that reads from the new column exclusively (still writing both, or writing only new if backfill is confirmed complete).
4. Contract: once all instances are confirmed on the new code path and no rollback is anticipated, drop the old column in a separate migration.

Skipping straight from step 1 to step 4 — the single most common cause of “zero-downtime deploy” incidents reported in postmortems — is the exact scenario interviewers are testing for when they ask “walk me through how you’d deploy a schema change without downtime.”

Connection Draining and In-Flight Requests

A subtler failure mode: even with correct traffic routing, in-flight requests get killed if old instances are terminated before they finish processing. The correct sequence:

1. Remove the old instance from the load balancer’s healthy pool (stop routing new requests to it).
2. Wait a drain period (typically 30-60 seconds, tuned to your p99 request duration) for in-flight requests to complete.
3. Send SIGTERM to the process, allowing graceful shutdown hooks to run (closing DB connections, flushing logs/metrics).
4. Only after the grace period elapses without process exit, send SIGKILL.

In Kubernetes specifically, this maps to terminationGracePeriodSeconds plus a preStop hook that sleeps briefly to let the endpoint removal propagate through kube-proxy/service mesh before SIGTERM is actually sent — a detail candidates frequently omit and that separates “read the Kubernetes docs” from “debugged a 502-spike-during-deploy incident.”

Load Balancer / DNS Considerations for the Cutover Itself

For true blue-green, the cutover mechanism matters:

• Load-balancer target group swap (e.g., ALB target group weighting): near-instant, but requires the LB to support atomic weighted routing.
• DNS-based cutover: simpler infrastructure but suffers from client-side DNS caching (TTL adherence is inconsistent across clients/resolvers), meaning “instant” rollback can take minutes in practice — a fact worth stating explicitly if DNS-based cutover comes up in an interview.
• Service mesh traffic shifting (Istio VirtualService weight adjustment): most granular, supports percentage-based and header-based routing for canary-within-blue-green patterns.

FAQ

Q: What’s the single biggest risk in a blue-green deployment? A: Database schema incompatibility between the old and new application versions during the window both are potentially live — not the traffic-routing mechanism itself, which is comparatively simple to get right.

Q: How long should the old (blue) environment stay up after cutover? A: Long enough to complete a full rollback if needed — typically until confidence in the new version is established through error-rate and latency monitoring, commonly 15 minutes to a few hours depending on traffic patterns and change risk.

Q: Is blue-green compatible with stateful services? A: Yes, but it requires the expand-contract migration pattern for schema changes and careful handling of any in-memory or session state that isn’t externalized to a shared store — a common interview follow-up when candidates propose blue-green without mentioning state.

For a structured walkthrough of infrastructure and systems-reliability interview questions including deployment strategy scenarios, see The 0-to-1 SWE Interview Playbook (https://www.amazon.com/dp/B0H256Z1MF?tag=sirjohnnymai-20).