Learn the vocabulary of routing a small slice of production traffic to a new version before a full rollout.
0 / 5 completed
1 / 5
A teammate explains that a new version of a service is first routed only a small slice of production traffic, say five percent, while the rest continues hitting the stable version, so problems surface on a limited blast radius before a full rollout. What deployment strategy is being described?
A canary deployment is exactly this: a small percentage of production traffic, such as five percent, is routed to the new version while the rest continues hitting the stable version, so any regression is caught on a limited blast radius, named after the canary used to detect danger in coal mines, before the new version is rolled out to everyone. A DNS zone transfer is an unrelated concept about replicating name server records. This small-slice-first approach is exactly why canary deployments are favored for catching regressions before they affect all users.
2 / 5
During a design review, the team adopts a canary deployment for a payments service update, specifically so a subtle bug in the new version only affects the small percentage of traffic routed to the canary before automated rollback triggers. Which capability does this provide?
A canary deployment here provides limited blast-radius risk exposure with an automated rollback path, since only a small traffic slice hits the new version until it proves healthy against error-rate and latency metrics. Routing one hundred percent of traffic to the new version immediately would expose every payment transaction to a subtle bug the moment it is deployed. This small-slice-then-expand behavior is exactly why canary deployments are favored for high-stakes services like payments.
3 / 5
In a code review, a dev notices a deployment pipeline pushes every new service version straight to one hundred percent of production traffic with no intermediate traffic-shifting stage, instead of first routing a small canary slice. What does this represent?
This is a missed canary-deployment opportunity, since routing a small slice first would limit the blast radius of a regression instead of exposing all traffic immediately. A cache eviction policy is an unrelated concept about discarded cache entries. This straight-to-one-hundred-percent pattern is exactly the kind of unnecessary exposure a reviewer flags once a gradual traffic-shifting stage is available instead.
4 / 5
An incident report shows a deployment that pushed a buggy new version straight to all production traffic caused a full outage, because there was no intermediate stage limiting how much traffic could hit the new version before problems were detected. What practice would prevent this?
Introducing a canary deployment stage that routes only a small percentage of traffic to the new version before expanding ensures a bug is caught on a limited blast radius instead of affecting every user at once. Continuing to push every new version straight to one hundred percent of traffic regardless of how many outages that has caused before is exactly what caused the outage described in this incident. This gradual-traffic-shift approach is the standard fix once straight-to-everyone deployments are confirmed to be causing full outages.
5 / 5
During a PR review, a teammate asks why the team reaches for a canary deployment instead of just deploying the new version to everyone at once and watching the dashboards closely, given that watching dashboards feels simpler than configuring traffic-shifting rules. What is the reasoning?
A canary deployment trades some traffic-routing configuration complexity for a bounded blast radius if something goes wrong, while deploying to everyone at once is simpler to configure but exposes all users the instant a regression ships. This is exactly why canary deployments are favored for high-risk rollouts, while deploying to everyone at once remains acceptable for very low-risk changes where dashboards can be watched closely.