MicroservicePatterns.com

Suggestions

  • PagePattern catalogAll patterns by category.
  • LabCircuit Breaker and Retries labCrash a dependency and tune the breaker.
  • LabSaga labFail a step and watch the compensations run.
  • PagePractice questionsScenario questions with explanations.
  • PageDesign reviewCheck your own architecture for anti-patterns.
Platform and deployment

Feature Flags Lab

A new checkout needs changes from four teams: payments, the checkout BFF, the web app and the mobile app. Each part is ready at a different hour over three days. Choose how the new checkout reaches customers, add a bug to the new code, and count the failed checkouts.

Background: Feature Flags, Externalized Configuration, Strangler Fig.

Scenarios
Release
What goes wrong

1,000 checkouts an hour. The four parts are ready in hours 7, 19, 31, 45. While only some parts run the new behaviour, 30% of checkouts fail. Someone notices when 20 checkouts fail in an hour; a flag is then switched off at once.

Starting
Payments serviceready hour 7Checkout BFFready hour 19Web appready hour 31Mobile appready hour 45NO FLAG: BEHAVIOUR CHANGES WHEN CODE IS DEPLOYEDCheckouts this hour: blue on the new checkout · red failed
–Failed checkouts this hour
–Failed checkouts so far
–Checkouts on the new code
0Part-hours of finished work held back
0%100%Checkouts on the new code3000Failed checkouts per hourstart24 h48 h72 h
Guided experiments

Run these in order

  1. Release each part as it deploys

    Four teams ship their part of the new checkout when it is ready. From the payments change in hour 7 until the mobile app in hour 45, some parts run the new behaviour and others do not, and almost a third of checkouts fail. Parts of one feature rarely land at the same moment.

  2. Hold everything and release together

    Every team waits for the last part, then all deploy at once. Nothing breaks, but finished work sits undeployed for 78 part-hours, and merging it all on one day is a risk of its own.

  3. Ship the big bang with a bug

    Same plan, but the new code fails one checkout in five. Everyone gets it at once, and the only way back is a redeploy that takes four hours, so 800 checkouts fail before it is undone.

  4. Deploy dark behind a flag

    Each part deploys when ready with the flag off, and the flag goes on in hour 47. Nothing waits and nothing breaks before release. When the bug shows up, the flag is switched off within the hour: 200 failures instead of 800.

  5. Roll out gradually

    Turn the flag on for 1%, then 10%, 50% and everyone, four hours apart. The bug is caught at 10% and switched off: 28 failed checkouts in all. A gradual rollout turns a bad release into a small one.

  6. Pay the price of caution

    The same gradual rollout, with no bug. Everyone has the new checkout by hour 59 instead of hour 47. Twelve hours is the cost of the safety, and the flag must be removed once the feature is fully on.

This lab simplifies reality on purpose. Traffic is flat, a bug fails the same share of checkouts from the first minute, and the on-call engineer reacts the moment a threshold is crossed. Real rollouts also watch error rates and business metrics automatically, target internal users first, and need the flag and the old code path removed once the feature is fully live.