Problem Statement
Deploying new versions of a service directly on the live environment can cause downtime or unexpected failures. If the new version has bugs, users experience errors or service interruptions, and rolling back is slow and risky.
0
0
Blue-green deployment in Microservices - System Design Guide
Solution
Blue-green deployment solves this by running two identical environments: one active (blue) serving all traffic, and one idle (green) with the new version. After testing the green environment, traffic switches instantly from blue to green, minimizing downtime and enabling quick rollback by switching back if needed.
Architecture
Load
Balancer
→Blue Env
Green Env
─────────────┘
This diagram shows a load balancer directing traffic to the blue environment, which is live. The green environment runs the new version and is idle until traffic switches over.
Trade-offs
✓ Pros
Zero downtime deployment by switching traffic instantly.
Easy rollback by switching back to the previous environment.
Safe testing of new version in production-like environment before release.
Reduces risk of deployment failures affecting users.
✗ Cons
Requires double infrastructure, increasing cost.
Data synchronization between environments can be complex.
Switching traffic may cause session or cache inconsistencies if not handled.
When you need zero downtime deployments and quick rollback for critical services with high availability requirements, typically at scale above hundreds of requests per second.
When infrastructure cost is a major constraint or the system state cannot be easily duplicated between environments, such as tightly coupled databases without replication.
Real World Examples
Amazon
Amazon uses blue-green deployment to release new versions of their e-commerce services without downtime, ensuring customers always have a smooth shopping experience.
Netflix
Netflix applies blue-green deployment to update streaming services, allowing instant rollback if new code causes playback issues.
Uber
Uber uses blue-green deployment to update ride matching services, minimizing disruption during peak hours.
Alternatives
Canary deployment
Gradually shifts a small percentage of traffic to the new version instead of switching all at once.
Use when:
When you want to monitor new version behavior on a small user subset before full rollout.
Rolling deployment
Updates instances one by one in place without maintaining two full environments.
Use when:
When infrastructure cost is a concern and small downtime or degraded performance is acceptable.
Summary
Blue-green deployment runs two identical environments to enable zero downtime releases.
It allows instant traffic switching and quick rollback to reduce deployment risks.
It requires extra infrastructure and careful data synchronization between environments.