patterntypescriptModerate
Canary testing: route a small percentage of traffic to the new version before full rollout
Viewed 0 times
canary deploymenttraffic splittinggradual rolloutproduction testingcanary metrics
Problem
A full deployment replaces all instances of the old version simultaneously. A bug in the new version affects all users immediately. Rollback restores the old version but the window of impact is the entire time between deploy and rollback.
Solution
Deploy the new version alongside the old and route 1-5% of real traffic to it (canary). Monitor error rate, latency, and business metrics for the canary cohort. If metrics are healthy, gradually increase traffic. If metrics degrade, roll back only the canary instances.
Why
Canary testing limits the blast radius of a production bug to a small percentage of users. Real traffic reveals bugs that staging environments miss (data distribution differences, third-party integrations, hardware-specific issues). The gradual rollout provides a natural gate at each traffic increment.
Gotchas
- Canary and old version must be compatible with the same database schema — avoid migrations that break old code
- Sticky sessions must route the same user to the same version throughout a session for stateful flows
- Define canary success criteria (error rate < 0.1%, p99 latency < baseline + 10%) before deployment, not after
- Canary deployments require infrastructure support (Kubernetes traffic splitting, AWS ALB weighted target groups, Istio)
Revisions (0)
No revisions yet.