Instead of switching every user to a new model at once, a canary release sends it only a small, growing slice of live traffic while the stable version keeps serving the rest. Each incoming request is a physical particle in this scene: it spawns at the load balancer, is routed toward whichever server its random draw falls into, and its outcome (success or error) is tallied at that server's monitor bar.
route(request) = canary if rand() < split
stable otherwise
split(t+dt) = split(t) + rampSpeed·dt if canary healthy
split(t+dt) = 0 if canary_errRate ≫ stable_errRate
- Canary traffic target — the split the rollout is trying to ramp toward, exactly like a Kubernetes/Argo Rollouts canary step.
- Canary error rate — how often the canary model's requests fail; crank it up to simulate shipping a genuinely worse model.
- Ramp speed — how fast live traffic climbs toward the target once the canary is judged healthy.
- Auto-rollback — when the canary's error rate is judged too high relative to the stable baseline, traffic is instantly withdrawn back to 0% — the automated safety net that makes canary releases safe to ship unattended.
Real-world relevance: this is the same pattern behind blue-green and canary deployments in real MLOps pipelines — a new model version proves itself on a shrinking blast radius of real traffic before it ever gets 100%, and a monitoring hook can undo the rollout automatically the moment metrics degrade.