A canary deployment trades a big risk for a sequence of small ones. This diagram walks the rollout: build the new version, deploy one instance, shift traffic through increasing percentages — 1%, 10%, 50%, 100% — with a metrics gate at every step. The mechanism is pure routing: the load balancer controls how much traffic each version receives, so the rollout is a series of configuration changes, not a series of deploys.
The ordering of the stages is the safety design. The canary starts tiny so that if the new version is catastrophic — a panic on boot, a broken request path — only a sliver of users feel it. Each shift is gated on a clean observation window, so problems surface at the smallest possible blast radius. And because rollback is just rerouting traffic, reverting is seconds rather than a redeploy. The failure model is worth stating plainly: a canary reduces the damage from bad releases; it does not eliminate them.