We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Reliability Resilience
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Reliability Resilience
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A canary rollout trickles traffic from 1% to 100% over 30 to 60 minutes. For many services that pace is fine. For financial services during market hours, for e-commerce during flash sales, or for any system where a half-deployed state is worse than no deploy at all, 30 minutes of mixed versions is unacceptable.
Blue-green solves this by maintaining two complete, identical environments. Blue is live. Green is warm and idle. You deploy to green, run smoke tests, and then flip one switch. All traffic moves from blue to green in seconds, not minutes. If green is broken, you flip the switch back to blue. The rollback is symmetric and takes the same seconds.
AWS Elastic Beanstalk ships blue-green as a built-in deployment mode. Spinnaker supports it natively. Martin Fowler coined the term in 2010, but the idea predates the name by years. Amazon runs mission-critical internal services on blue-green when the cost of a mixed-version state during a rolling deploy exceeds the cost of running two parallel environments.
The trade-off is compute cost. You pay for double the infrastructure during every deploy window. For a 50-pod service, that is 50 extra pods for 10 to 30 minutes. The cost is real but small compared to the operational cost of a rolling deploy that gets stuck halfway through during a peak traffic window.
The mechanism is simpler than most teams expect. The entire deployment is just three phases.
| Phase | What Happens | Duration | Risk to Users |
|---|---|---|---|
| Prepare | Deploy new version to green, run smoke tests | 5-10 minutes | Zero, green is idle |
| Cutover | Flip from blue to green | Seconds | Near zero, brief /LB propagation |
| Hold | Watch metrics, keep blue warm | 10-30 minutes | Green is live, blue is the safety net |
The smoke tests are the first gate. Playwright scripts hit the top 20 user journeys on the green environment. If any test fails, the cutover is cancelled with zero user impact because green never received real traffic. Most teams run smoke tests in under 2 minutes.
The cutover itself is a load balancer target group swap or a DNS record update. ALB target group swaps complete in under 10 seconds. DNS updates depend on , which is why most teams standardize on load balancer swaps for routine deploys and reserve DNS for scheduled maintenance windows.
The hold period is the insurance window. Blue stays warm and serving nothing for 10 to 30 minutes. If green shows trouble, the team flips back to blue with one command. After the hold, blue is decommissioned and the extra compute is released.