Blue Green Deployment Zero Downtime Migration

Why Deployment Strategy Questions Appear In SWE Interviews

Beyond pure system design, senior and staff interviews increasingly probe operational maturity: “how would you deploy this without downtime?” or “how do you migrate this database schema safely in production?” Blue-green deployment is the canonical answer pattern, and interviewers use it to test whether you understand the difference between deploying code and migrating state, which is where most real production incidents actually happen.

What Blue-Green Deployment Is

Blue-green deployment maintains two identical production environments, “blue” (currently live) and “green” (the new version). You deploy the new release to green, run smoke tests and health checks against it while blue still serves all live traffic, then switch the router/load balancer to send traffic to green. If something breaks, you flip back to blue instantly, since it never stopped running. This gives you near-zero downtime and, critically, an instant rollback path measured in seconds rather than the minutes-to-hours a redeploy-and-hope rollback takes.

Contrast this with rolling deployment (replacing instances gradually, one at a time) and canary deployment (routing a small percentage of traffic, 1-5%, to the new version before full rollout). Blue-green trades higher infrastructure cost (you’re running two full environments simultaneously, even if briefly) for the fastest possible rollback and the cleanest all-or-nothing traffic cutover.

The Hard Part: Database Migrations

Interviewers who ask this question are almost always fishing for whether you understand that blue-green deployment is easy for stateless application code and genuinely hard for stateful data layers. If blue and green share the same database, and the new code requires a schema change, you cannot simply “flip a switch,” because the old (blue) code may break against the new schema, or vice versa, during the cutover window.

The standard solution is the expand-contract pattern (also called parallel change): (1) Expand: add new columns/tables without removing old ones, deploy code that writes to both old and new schema, keeping the old code (blue) still fully compatible. (2) Migrate: backfill historical data into the new schema, verify consistency between old and new representations. (3) Contract: once green is fully live and stable (typically after a soak period of hours to days), deploy a final change that removes the old schema/columns. This means every schema-changing deploy is actually three deploys, not one, which is the detail that separates strong answers from superficial ones.

Traffic Cutover Mechanics

The switch itself happens at the load balancer or DNS layer. In 2026, most teams use one of three mechanisms: (1) a load balancer target group swap (AWS ALB/NLB target group re-registration, Kubernetes Service selector update), which is near-instant (sub-second) and the preferred method when both environments run in the same cluster/VPC; (2) DNS-based cutover (Route 53 weighted records), which is simpler operationally but suffers from DNS TTL/caching delays, meaning some clients keep hitting blue for minutes after the switch due to resolver caching; (3) service mesh traffic splitting (Istio VirtualService weight adjustment), which allows gradual percentage-based shifting, effectively blending blue-green with canary semantics, and is now the default at companies already running a mesh for other reasons.

Kubernetes-native blue-green, using two Deployments and swapping a Service’s label selector, has become the most common implementation pattern for teams on Kubernetes by 2026, since it requires no additional infrastructure beyond what’s already running.

Comparison Table

What Interviewers Want To Hear

Structure your answer around three explicit points: state that blue-green solves the code deployment problem cleanly but the database problem requires expand-contract regardless of deployment strategy; name the specific cutover mechanism you’d use given the stated infra (load balancer swap for same-cluster, DNS weighted routing for multi-region); and proactively raise the soak-period question, how long do you keep blue running as a rollback safety net before decommissioning it (industry norm: anywhere from a few hours for low-risk services to several days for critical payment/checkout paths).

Also mention feature flags as a complementary technique: decoupling “deploy” from “release” via a flag system (LaunchDarkly, Unleash, or an in-house flag service) lets you deploy new code to 100% of green instances but only activate the new behavior for a subset of users, which reduces reliance on infrastructure-level traffic splitting for behavioral rollout control.

For more structured practice turning operational scenarios like this into a compelling interview narrative, The 0-to-1 SWE Interview Playbook (https://www.amazon.com/dp/B0H256Z1MF?tag=sirjohnnymai-20) covers deployment strategy questions as part of its systems-in-production chapter.

FAQ

Q: Does blue-green deployment eliminate the need for database migration planning? A: No. It solves zero-downtime code cutover, but any schema change still requires the expand-contract pattern so both blue and green code can operate against a shared database without breaking each other during the transition window.

Q: How long should you keep the old (blue) environment running before decommissioning it? A: It depends on the blast radius of the service. Low-risk internal tools: a few hours is common. Payment or checkout-critical services: teams often keep blue on standby for 24-72 hours to catch delayed-onset issues (e.g., a bug that only surfaces during nightly batch jobs) before tearing it down.

Q: Is blue-green more expensive than rolling deployment? A: Yes, temporarily. You run two full production environments simultaneously during the cutover window, which roughly doubles compute cost for that period, though the window is typically short (minutes to a few hours) compared to running that cost continuously.