Problem
Big bang deployments risk 100% impact. Rollback takes time. Canary limits blast radius to small percentage.
deploymentestablished · medium operational burden
Canary Deployment
Also known as: canary-release, progressive-delivery, canary
Intent
Gradually shift traffic to new version, monitoring for regressions before full rollout.
Forces
- •Need to validate new version with real traffic
- •Rollback must be instant (traffic shift, not redeploy)
- •Metrics must detect regressions automatically
- •Multiple versions run simultaneously
Solution
✓ When to Use
- •Continuous deployment pipeline
- •Risky changes: schema, algorithm, third-party upgrade
- •User-facing services with measurable metrics
✗ When Not to Use
- •Infrastructure changes (no traffic to split)
- •Single-instance services (no parallel versions)
- •Team not ready for observability investment
Pros
- +Blast radius: 1-5% instead of 100%
- +Instant rollback: traffic shift < 30s
- +Real traffic validation (not staging)
- +Automated promotion/rollback
Cons
- −Requires: observability, traffic splitting, automation
- −Two versions running: schema compatibility needed
- −Longer deployment time (phases)
- −False positives/negatives in metric analysis
Cost Profile
Infrastructure
Low — uses existing LB/mesh
Operational
High — pipeline, metrics, automation
Cognitive
Medium — progressive delivery concepts
Failure Modes
Metric noise → false promotion/rollback
Schema incompatibility → errors in canary
Sticky sessions → uneven distribution
Long-running requests span versions → inconsistency
Automation bug → stuck promotion, manual intervention
Real-World Examples
Alternatives
- blue-green
- rolling-update
- feature-flag
- dark-launch
Related Patterns
- blue-green
- rolling-update
- feature-flag
- observability
- service-mesh
Competency Domains
deploymentreliability opseconomics evolutiondistribution communication