Blue-Green Traffic Switch
A blue-green traffic switch flips the router from the blue environment to green in one step, so the new version is live with no in-place upgrade and rollback is a router flip back.
Definition
Blue-green traffic switch is the deployment technique where two identical environments (blue, green) run side by side, the new version is deployed to the idle one, and the router is switched to send all traffic to it in one step, so that deployment is atomic and rollback is a router reversal to the previous environment.
Context and scope
Applied in stateless services, load-balanced deployments, and any system where an in-place upgrade risks a mixed-version state and a router switch is feasible.
Common misconceptions
- Blue-green is just a canary — a canary ramps traffic gradually; blue-green switches all at once, which is faster but higher blast radius
- Blue-green requires double capacity — it requires double capacity during the switch; after verification the old environment can be drained
Anti-patterns
- Switching traffic to green without warming it, so the first requests hit cold caches and the new version looks slower than the old
- Keeping blue and green running indefinitely, paying double capacity for a deployment that is complete
Related concepts
Authoritative source
What it is
Blue-green traffic switch is the deployment technique where two identical environments (blue, green) run side by side, the new version is deployed to the idle one, and the router is switched to send all traffic to it in one step, so that deployment is atomic and rollback is a router reversal to the previous environment. Applied in stateless services, load-balanced deployments, and any system where an in-place upgrade risks a mixed-version state and a router switch is feasible. The unit of delivery is the deployable artifact plus its configuration, and the goal is to move changes to production safely, quickly, and reversibly.
How it works
Safety comes from small batches (less change per deploy means less blast radius), automated canaries (a bad change is caught at 1% before it reaches 100%), and reversible deployments (rollback is the default escape, not a rewrite). Speed comes from pipeline parallelism and eliminating the manual gates that batch up changes. Every step produces evidence — test results, scan output, canary metrics — that the next step consumes.
When to apply and pitfalls
Apply whenever the cost of an incident exceeds the cost of the pipeline that prevents it. The pitfall is optimizing deploy speed without investing in the observability and rollback that make speed safe — fast deploys of broken code just reach the outage sooner. Another is treating the pipeline as a checklist rather than a feedback loop that improves with each deployment.