Canary Release
Routing a small fraction of traffic to a new version, watching its metrics, and expanding or rolling back based on what they show.
Start at 1%, compare error rate and latency against the stable version, then step to 5%, 25%, 100%. The point is to bound the blast radius of a bad release to a small population, and to get real production signal that no pre-production environment can produce.
What makes it work is not the traffic splitting — that part is easy — it is having metrics that distinguish the canary from the baseline, and an automated rollback trigger. A canary that a human has to watch is a canary that gets ignored at 6 PM on Friday.
Two things that break it: sticky sessions, which mean a user who lands on the canary stays there regardless of the percentage, and asynchronous work, where the canary consumes from a shared queue and therefore processes far more than its traffic share suggests.