Blue-Green or Canary Replacement¶
Rollout procedure — instantiates Encapsulated Substitutability
Runs the substitute alongside the incumbent on a small, reversible slice of real traffic, and only widens the cutover once observed behavior earns each step.
Blue-Green or Canary Replacement limits the blast radius of a swap by staging it. Blue-green keeps two full environments and flips traffic between them; canary routes a small percentage to the substitute and grows that share step by step. Either way, the substitute meets real load in a bounded, reversible slice, and promotion to more traffic is gated on observed behavior. Its defining move is that it buys evidence in production, under real conditions, while keeping the cost of being wrong small — distinct from pre-deployment testing (synthetic) and from design-time comparison (on paper).
Example¶
A payments platform wants to replace its fraud-detection model. Offline metrics look better, but offline is not production. So it routes about 2% of live transactions through the new model while the other 98% stay on the incumbent, and watches approval rate, false-decline complaints, chargeback signal, and latency — with the incumbent's traffic serving as a live control. For a week the canary holds within the error budget; the team widens exposure to 10%, then 50%, then full, pausing at each gate. Had declines spiked at any step, traffic would flip back at once. What would have been a single risky cutover becomes a sequence of small, reversible bets, each one promoted only after the last earned it.
How it works¶
Three things distinguish it. Traffic is partitioned — a slice runs on the substitute while the rest stays on the proven incumbent, which doubles as a live control. Each widening is a promotion gate with explicit criteria, not an automatic ramp. And a fast reversal route stands ready so a failed step costs little. Blue-green makes the flip atomic (whole environments switch at once); canary makes exposure gradual (a rising percentage). Both keep the incumbent warm precisely so that reversal is cheap.
Tuning parameters¶
- Exposure schedule — the initial percentage and how fast it ramps (2 → 10 → 50 → 100, quickly or slowly). Faster reaches confidence sooner but raises the blast radius of each step.
- Slice selection — random percentage, by region, by tenant, or internal-users-first. Non-random slices lower risk but can be unrepresentative of the whole.
- Gate criteria and dwell time — which metrics gate promotion, and how long a stage must hold clean. Long dwell catches slow-burn regressions but delays the cutover.
- Shadow vs. live — mirror traffic to the substitute without acting on its output, versus letting it act. Shadow is safe but cannot observe real side effects.
- Reversal trigger — manual rollback versus automatic on breach, and how tight the auto-trip is set.
When it helps, and when it misleads¶
Its strength is that it converts a risky swap into reversible increments and catches under real load what tests miss — the named practices of blue-green deployment and canary release. Its honest failure mode is that a canary only reveals problems that surface within its slice and its window: scale-dependent or slow-burn regressions can pass a small, short canary and then appear at full cutover, and an unrepresentative slice flatters the substitute. The classic misuse is declaring victory after a too-small, too-short canary because a launch date looms. The discipline that guards against it is to gate promotion on staying inside an explicit error budget,[n1] size and time the canary to the actual risk, and keep the incumbent warm until confidence is real.
How it implements the components¶
Blue-Green or Canary Replacement fills the staged-rollout subset — the parts a controlled cutover operates:
parallel_run_window— it runs incumbent and substitute simultaneously on partitioned real traffic, with the incumbent serving as the live control.substitution_gate— each promotion step is a gate: observed behavior must clear stated criteria before exposure widens, or the step reverses.
It does not reconcile the two runs cell-by-cell for correctness — that comparison is Parallel Run Reconciliation and Golden Master or Trace Comparison — and it does not itself perform the reversion; it pulls the Fallback Switch or Kill Switch when a gate fails.
Related¶
- Instantiates: Encapsulated Substitutability — it is how a validated substitute actually takes over, without a single all-or-nothing leap.
- Consumes: Fallback Switch or Kill Switch for the reversal route; Service-Level Regression Monitor for the signal each gate reads.
- Sibling mechanisms: Fallback Switch or Kill Switch · Parallel Run Reconciliation · Service-Level Regression Monitor · Adapter or Facade Layer · Dependency Injection or Plugin Slot · Capability Equivalence Matrix · Contract Test Suite · Golden Master or Trace Comparison · State Migration Playbook · Supplier or Model Homologation
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Runs the substitute alongside the incumbent on a small, reversible slice of real traffic, and only widens the cutover once observed behavior earns each step, making its operative form a deliberate probe, variation, simulation, or practiced execution used to generate evidence or readiness.
Independent corroboration: The frozen evidence defines Blue-Green or Canary Replacement as 'Runs the substitute alongside the incumbent on a small, reversible slice of real traffic, and only widens the cutover once observed behavior earns each step', so its operative form is Experiment, Test & Rehearsal.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Software deployment engineering created blue-green and canary releases: partition traffic, promote by explicit gates, keep the incumbent warm, and reverse quickly on failure.
Review resolution: The terminology, traffic partitioning, live promotion gates, warm incumbent, and rapid rollback are specifically software deployment engineering. Parallel commissioning is an engineering analogy, not a co-origin of blue-green or canary release practice.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
A parallel run assumes the substitute's actions are either shadowed or idempotent. Where a step has irreversible side effects — sending real notifications, moving real money, actuating hardware — canarying on live traffic can double-act: both incumbent and substitute do the thing. For those cases, shadow the substitute first, or partition by entity so each request is handled once, before letting the canary act for real.
[n1] Error budget (Google Site Reliability Engineering): the tolerated amount of failure — for example, the margin below a 99.9% availability objective — over a window. Used as a canary's promotion gate, it converts "does it look OK?" into "has it stayed within budget?", withholding promotion (or forcing rollback) once the budget is spent. ↩