The question this answers
Which rollout strategy fits this workload, and what does each one demand from the code and the database in return?
A new version must replace the running one without dropping requests, and a bad version must stop serving within minutes rather than after a rebuild — for a service that also cannot afford to double its capacity for an hour.
A controlled transition from one running version to another, with an explicit position on how long the old version keeps serving, how fast you can go back, and how much extra capacity that costs.
The four strategies, side by side
Recreate stops the old version and starts the new one. There is a gap. It is the only strategy that does not require the two versions to coexist, which makes it the correct choice more often than its reputation suggests — a nightly batch job, an internal tool, or a change with an incompatible schema migration is genuinely better served by a two-minute maintenance window than by an elaborate compatibility dance.
Rolling replaces instances in batches, so both versions serve simultaneously and capacity stays roughly constant. It is the default on most orchestrators. Its cost is not money; it is the compatibility requirement, which is easy to state and easy to forget. See Rolling Deployment and the Compatibility It Demands.
Blue/green stands up a complete second environment, verifies it, then switches traffic at the load balancer. Rollback is a switch back, measured in seconds. The cost is roughly double capacity during the overlap, and the fact that the database does not switch with it. See Blue/Green: Two Environments, One Switch.
Canary sends a small fraction of traffic to the new version, watches metrics, and increases the fraction if they hold. It has the lowest blast radius of the four and the highest requirement: without metrics good enough to decide on, it is just a slow rolling deploy with extra steps. See Canary: Let 5% of Traffic Find the Bug.
| Strategy | Rollout speed | Rollback speed | Capacity cost | Blast radius of a bad version | Compatibility required |
|---|---|---|---|---|---|
| Recreate | Fast | Redeploy old version (slow) | None | 100% of traffic, for the duration | None — versions never coexist |
| Rolling | Medium | Roll back through the same batches (medium) | Small surge (one extra batch) | Grows as the rollout proceeds | N and N+1 must coexist: API, schema, cache, queue messages |
| Blue/green | Fast switch after a slow build-up | Seconds — switch back | ≈2× during overlap | All traffic at once after the switch | Shared database must serve both versions |
| Canary | Slow and deliberate | Seconds — shift traffic back | Small surge | Limited to the canary fraction | Same as rolling, plus metrics good enough to gate on |
The question that actually decides it
Teams usually argue about rollout speed. The decision is nearly always made by something else: whether two versions of your code can safely run against one database at the same time. Every strategy except recreate requires that they can. If the release renames a column, changes the meaning of an enum value, or writes a message format the old consumers cannot parse, then a rolling deploy is not a safer recreate — it is a recreate with a window during which half the fleet is producing data the other half misbehaves on.
So the sequence is: first decide whether this particular release is coexistence-safe. If it is not, either make it safe (expand-and-contract, over two releases) or accept a short window with recreate. Only after that does the speed-versus-cost-versus-blast-radius comparison matter.
The second decision is about signal. Canary is the strongest strategy on paper and it is only as good as the metrics that gate it. If you cannot answer "would a 3% error-rate increase in the canary group be visible within five minutes?", canary is theatre. Build the observability first — this is the cross-link that matters most in this module. See Infrastructure Observability.
What each strategy costs while it is running
The capacity cost is the visible one and it is temporary, which is why it is usually acceptable: doubling for twenty minutes is a rounding error on a monthly bill. The costs that persist are the ones built into the delivery path — a traffic-splitting layer to maintain, per-version dashboards, an automated rollback trigger, and the discipline of writing every schema change in two steps.
There is also a cost to *not* choosing well. A rolling deploy of a coexistence-unsafe release produces an incident whose symptoms are intermittent and version-dependent, which is among the hardest classes of production bug to diagnose — the same request succeeds or fails depending on which instance answered it.
Bars are relative weights, not currency. Real rates depend on provider, region, commitment and volume.
Key points
- Recreate, rolling, blue/green and canary differ on rollout speed, rollback speed, capacity cost and blast radius.
- The deciding question is usually compatibility: can N and N+1 run simultaneously against one database?
- Recreate is the correct answer more often than its reputation suggests — batch jobs, internal tools, and incompatible migrations.
- Canary has the smallest blast radius and the largest prerequisite: per-version metrics good enough to gate on.
- Capacity cost is temporary; the traffic-splitting layer and the two-step migration discipline are permanent.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • Recreate: stop all instances of N, start instances of N+1. No overlap, therefore no coexistence requirement.
- • Rolling: replace instances in batches, waiting for readiness before removing the next batch from the load balancer.
- • Blue/green: provision a full N+1 environment alongside N, verify it out of band, then repoint the load balancer or DNS.
- • Canary: route a weighted fraction of traffic to N+1 at the gateway, compare metrics per version, then increase the weight or shift it back.
- • In all four, the load balancer's readiness check is what decides when an instance is allowed to receive traffic — see Liveness vs Readiness.
- • You own the compatibility decision per release, which is a code-review question rather than an infrastructure one.
- • You own the rollback trigger: what condition, measured how, acting automatically or paging a human.
- • You own the traffic-splitting layer if you use canary, including its own upgrades and failure modes.
- • You own the deploy window policy — whether deploys happen during peak, and who is watching for the first ten minutes.
- • You own draining and shutdown behaviour, without which every strategy drops requests. See Graceful Shutdown: The 502 Spike Nobody Investigates.
- • A rolling deploy of a coexistence-unsafe release: intermittent, version-dependent errors that are extremely hard to attribute.
- • A readiness probe that passes before the application can serve, so the rollout proceeds and traffic hits instances that fail.
- • A rollback that is not actually available: blue was torn down immediately after the switch, or the previous artifact was garbage-collected.
- • A canary too small to be statistically meaningful, so the gate passes on noise and the bad version rolls to 100%.
- • A schema migration applied at deploy time that the old version cannot tolerate, which converts any strategy into recreate with extra downtime.
- • A deploy at peak with nobody watching, discovered by customer reports rather than by the error-rate alarm.
- • Rollout duration scales with instance count divided by batch size; large fleets spend a long time in the mixed-version state, which raises the value of compatibility discipline.
- • Blue/green's capacity cost scales linearly with fleet size, which is what makes it unattractive for very large fleets and trivial for small ones.
- • Canary's statistical power scales with traffic: at low request rates the canary fraction has to be large or the observation window long, or the gate decides nothing.
- • Per-version metric cardinality scales with series count times versions in flight, and it is the observability cost that surprises people.
- • The deploy path can replace running code, so the strategy is implemented by the most privileged identity in the system. See The Pipeline as Infrastructure.
- • Canary and blue/green both need a traffic-routing layer that can be misconfigured into exposing an unverified environment publicly — verify green privately before it is reachable.
- • A fast, tested rollback is a security control: it is how you remove a version with a newly disclosed vulnerability in minutes rather than in a release cycle.
- • Mixed-version windows can mean mixed security posture — an authorisation fix is only fully in effect once every instance has it.
- • Capacity surge is spiky and short: blue/green roughly doubles briefly, rolling adds one batch, canary adds a small fraction.
- • The permanent costs are the routing layer and per-version metric cardinality, not the compute.
- • The largest cost is the one being avoided: error rate times traffic times time-to-rollback. Strategy choice is mostly a bet about that product.
- • Error rate, latency percentiles and saturation split by version — without the version dimension none of these strategies can be gated.
- • Rollout progress: instances at the new version, readiness failures, time in mixed state.
- • Time to rollback, measured from decision to traffic actually moved. This is the number that justifies blue/green.
- • Deploy frequency and change failure rate over time, which say whether the strategy is working.
- • The signal that lies: overall aggregate error rate during a canary. A 5% canary with a 100% failure rate moves the aggregate by 5%, which looks like noise on a weekly dashboard.
- • Recreate with a short announced window. For internal tools, batch jobs and anything with an incompatible migration this is simpler, cheaper and more honest than pretending to do zero-downtime.
- • Deploy dark and release with a flag, which separates the rollout risk from the behaviour-change risk entirely. See Deployment Is Not Release.
- • Rolling only. Most teams do not need canary; they need readiness probes that are correct and someone watching the first ten minutes.
- • For a single-instance service, there is no strategy — there is a restart. Adding a rollout strategy before adding a second instance is solving the wrong problem.
- • Faster rollback costs capacity (blue/green) or routing infrastructure (canary).
- • Smaller blast radius costs rollout time, and a long rollout means a long mixed-version window.
- • Zero downtime costs a permanent compatibility discipline on every schema and contract change; recreate buys that back for the price of a window.
Rolling, blue-green, canary, recreate
What people believe, and what is true
Rolling deployment is the safe default.
It is the low-cost default. It is only safe if N and N+1 can coexist, and nothing in the rollout configuration checks that for you.
Canary is strictly better than the others.
Canary without per-version metrics is a slow rolling deploy that costs a routing layer. The prerequisite is the substance.
Downtime is never acceptable.
A two-minute window on an internal reporting tool at 06:00 is cheaper and less risky than the compatibility work required to avoid it. Choose deliberately, not reflexively.