Deployment Simulator
A candidate version with a defect in it, rolled out four different ways. The strategies differ in how much capacity they cost, how many users they expose, and — the part people reason about worst — how much evidence they give you before it is too late to act on it.
Instance counts and traffic fractions are exact because they are configuration. The error rates are your premise, not an observation: you are stating “suppose v2 fails this fraction of the requests it sees” and reading off what each strategy would then show you. No figure on this page came from a real system.
Replace instances a batch at a time, so old and new serve simultaneously.
Both versions run against the same database and the same consumers, so every change must be backward compatible.
Low — a small amount of extra capacity during the roll, or a small dip if you do not add any.
Roll the other way, which takes as long as the rollout did.
The default for stateless services whose changes are backward compatible.
The premise
Change any of these and the whole rollout is recomputed.
The rollout, step by step
Read the capacity column and the detectable column together. They are the two things a strategy trades against each other.
| Step | Instances | Traffic to v2 | Capacity | Running | Observed errors | Detectable |
|---|---|---|---|---|---|---|
Steady state on v1 Everything is serving the old version. | 1111 | 0% | 100% | 4 | 0.20% | no |
1 of 4 on v2 Old and new serve at the same time. Both are talking to the same database, which is why a migration here has to be backward compatible. | 2111 | 25% | 100% | 4 | 0.95% | yes |
2 of 4 on v2 Old and new serve at the same time. Both are talking to the same database, which is why a migration here has to be backward compatible. | 2211 | 50% | 100% | 4 | 1.70% | yes |
3 of 4 on v2 Old and new serve at the same time. Both are talking to the same database, which is why a migration here has to be backward compatible. | 2221 | 75% | 100% | 4 | 2.45% | yes |
4 of 4 on v2 Old and new serve at the same time. Both are talking to the same database, which is why a migration here has to be backward compatible. | 2222 | 100% | 100% | 4 | 3.20% | yes |
Fully on v2 Rollout complete. Rolling back now costs another full roll in the other direction. | 2222 | 100% | 100% | 4 | 3.20% | yes |
What the rollout cost you
Two numbers about capacity, two about evidence.
The lowest fraction of the target that was able to serve at any step.
What you pay for at the most expensive moment of the rollout.
The earliest step at which the defect moves the overall error rate above normal variation.
The fraction of users already receiving the defect by the time it became visible.
The defect rises above noise once 25% of traffic is on v2. Capacity dipped to 100% and peak running instances were 4.
What “detectable” means here, and what it does not
The column says yes when the defect pushes the observed error rate further above baseline than the normal variation you entered. That is a signal-versus-noise comparison and nothing more. It is not a statistical test, it is not a confidence level, and it is not a decision procedure. A real canary analysis compares the candidate against a concurrent baseline over a window, accounts for how many requests each has actually served, and can still be wrong.
The reason the simplification is still worth having is the shape it exposes: a small canary bounds the damage and bounds the evidence. Set the v2 error rate below the noise and every strategy reports “never” — the rollout completes, the dashboards stay green, and the defect is live at full exposure. That is the uncomfortable case, and it is the one that argues for comparing the candidate specifically rather than watching an aggregate.