Problem
Deployments cause downtime or errors during transition. Rollback requires redeploying previous version.
deploymentestablished · medium operational burden
Blue-Green Deployment
Also known as: blue-green, red-black, zero-downtime-deployment
Intent
Run two identical environments (blue, green). Switch traffic atomically for zero-downtime deployments with instant rollback.
Forces
- •Zero downtime required
- •Instant rollback capability
- •Full validation before traffic switch
- •Infrastructure supports duplicate environments
Solution
✓ When to Use
- •Zero-downtime requirement
- •Instant rollback critical
- •Infrastructure supports duplicate envs (K8s namespaces, ASGs)
- •Team can maintain schema compatibility
✗ When Not to Use
- •Stateful services without session handling
- •Breaking schema changes (need expand/contract)
- •Cost-sensitive: 2x infrastructure
- •Long-running transactions (drain complexity)
Pros
- +True zero-downtime (atomic switch)
- +Instant rollback (switch back)
- +Full validation before traffic
- +No version overlap in production traffic
Cons
- −2x infrastructure cost during deployment
- −Schema changes: must be backward compatible
- −Long-running requests: drain before switch
- −Database migrations: expand/contract discipline
Cost Profile
Infrastructure
High — 2x capacity during deploy
Operational
Medium — switch automation, validation
Cognitive
Low — simple concept
Failure Modes
Switch mechanism fails → split brain
Schema incompatibility → errors after switch
Session loss: users logged out
Validation gaps: issues only appear under real load
Green environment drift: not truly identical
Real-World Examples
Alternatives
- canary-deployment
- rolling-update
- feature-flag
- rolling-restart
Related Patterns
- canary-deployment
- rolling-update
- expand-contract
- database-migration
- feature-flag
Competency Domains
deploymentreliability opsdata stateeconomics evolution