Ordering: ship a new checkout with canary and feature flags Intermediate

A risky checkout change should not reach every customer at once. Canary and feature flags let you raise exposure one notch at a time, but only when the steps run in the right order: schema before code, deploy before release, abort criteria before anyone sees the feature.

Order the 7 steps below. Press Check to see which steps are out of place and what breaks when they are.

Ordering

Releasing a new checkout with a canary and a feature flag

Checkout v2 changes how promotions are calculated and writes the details into a new column orders.discount_breakdown. Checkout runs on 20 pods with rolling deploys, SLO: 99.9% of checkout requests succeed, p99 ≤ 800 ms.

Order the steps so that at every moment you can turn it off within seconds and no user hits an error caused by the wrong order.

Use ▲▼ to move each step, or tap a step’s ⠿ and then tap its new position. On a computer you can drag and drop.

1. 1⠿Deploy the new version with flag checkout_v2 defaulting to off: canary on 1/20 pods, compared against the other 19, then roll out fully if it passesfallback when the flag service does not respond: false▲▼
2. 2⠿Expand migration: add the nullable column discount_breakdown under a lock_timeout▲▼
3. 3⠿Ramp 1% → 10% → 50% of customers by user_id hash, holding each step long enough and comparing the v2 cohort against control▲▼
4. 4⠿Build a dashboard splitting cohorts by the variant label the new version emits, agree on abort criteria and who has the authority to turn the flag offabort if the v2 cohort: error rate 0.1 percentage points above control, or p99 > 800 ms, for 10 minutes▲▼
5. 5⠿Turn on 100%, keep the flag for one more peak cycle as a kill switch▲▼
6. 6⠿Remove the flag and the old checkout path in a separate deploy▲▼
7. 7⠿Turn the flag on for internal employees, place a few real orders with popular promo codes▲▼

Check order↺ Shuffle again

The lifecycle of a release flag and how to avoid flag debt: Config on Kubernetes.