DevOps
Canary Deployment
Release a new version to a small percentage of users first, watch error rate and latency, then gradually widen the rollout or roll back if the metrics degrade. It limits the blast radius of a bad release. It relies on good monitoring and traffic-splitting, and on tolerating two versions running side by side.
Purpose
A canary release sends the new version to a small slice of real traffic — say 5% — while the rest stays on the stable version. Metrics from the canary (error rate, latency) decide whether the rollout widens or reverses. It limits the blast radius of a bad release to the few, not the many.
When to Use It
High-traffic services where even brief full-fleet breakage is costly, risky changes (runtime upgrades, dependency bumps), and gradual feature rollouts. Feature flags achieve a similar effect at the application layer, decoupling release from deploy.
Trade-offs
It needs infrastructure for weighted traffic-splitting and — crucially — monitoring good enough to judge the canary automatically; without trustworthy metrics a canary is theatre. Two versions run side by side, so data and API compatibility between them is mandatory.
Implementation
Split traffic by weight at the load balancer, mesh or gateway; define the success metrics and thresholds up front; automate promotion and rollback on those metrics rather than vibes. Start with internal users or one region, and widen in steps (5% → 25% → 100%) with soak time between.