Problem Statement: Blue-Green at Scale
How Problem Statement: Blue-Green at Scale (understanding) informs Blue-Green Deployment architecture and interviewer depth.
Problem Statement: Blue-Green at Scale
Core Mechanism
- Maintain parallel stacks behind a single traffic plane (ALB, Envoy, or DNS weighted records).
- Promote only after synthetic + production-like smoke checks pass on green.
- Keep blue warm until error budgets recover; rollback is a routing change, not a rebuild.
Operational Invariants
- Idempotent releases — same artifact version on both stacks before cutover.
- Backward-compatible schema — expand-contract migrations; never break blue readers during green deploy.
- Observable cutover — golden signals (5xx rate, p99 latency, checkout success) gated on promotion.
Interview Signal
State explicit RTO for rollback (<60s routing flip) and RPO for data (replication lag bound). Netflix-style teams pair blue-green with feature flags for code path toggles while routing stays stable.
How to open this one
The strongest framing for blue-green is that it buys instant, atomic rollback at the price of double capacity: two identical production environments, one live, traffic flipped at the load balancer in a single move. Lead with that trade-off — the cost of the idle fleet versus seconds-to-rollback — and the failure story that proves it: the green environment regresses right after the flip, and you cut traffic straight back to blue, which is still warm. That shows you understand when this strategy earns its cost.
Key Highlights
- •Rollback is routing, not rebuild — keep blue warm until SLOs recover
- •Gate promotion on golden signals, not only CI green checks
- •Treat schema changes as expand-contract, never big-bang with dual stacks
- •Budget ~2x production compute for steady-state dual environments
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "Rollback is a routing change back to blue; we never rebuild under incident pressure."
- "We gate promotion on golden signals, not only deployment job success."