Challenge 1: Choose a Strategy for a High-Traffic Checkout Flow — Possible Solution
====================================================================

SCENARIO: An e-commerce site's checkout flow, processing real payments,
that can't tolerate serving a broken version to a large fraction of
users even briefly.

RECOMMENDATION: Canary deployment (with blue-green as a strong
secondary consideration)

JUSTIFICATION (using this chapter's table)
------------------------------------------------
- This chapter's own table lists canary's blast radius as "small,
  controlled" — directly matching the scenario's explicit requirement
  of not tolerating exposure to "a large fraction of users." A canary
  rollout starting at 5% means a broken checkout flow would only ever
  affect a small slice of real transactions before automated health
  checks (this chapter's own rollback mechanism) catch the problem and
  roll it back — precisely the "catching problems automated tests
  missed while only a small number of users are affected" advantage
  described for canary deployment.
- Rolling deployment is explicitly weaker on this exact dimension: the
  table describes its blast radius as one that "grows as rollout
  proceeds" — for a payment-processing flow, this means an
  increasing number of real transactions could be affected the longer
  a bad deploy goes undetected, which is a poor fit for a scenario that
  explicitly cannot tolerate broad exposure.
- Blue-green is also a genuinely reasonable choice here: its "all-or-
  nothing at the switch" blast radius means either 0% or 100% of
  traffic sees the new version, with "instant" rollback if something's
  wrong. For a truly critical flow, some teams would prefer blue-green
  specifically because problems are caught via testing on the idle
  environment BEFORE any real traffic sees it at all, rather than
  canary's approach of exposing SOME real users (even if only 5%)
  during the verification process itself.
- The higher infrastructure cost of blue-green (or the moderate cost of
  canary) is a reasonable tradeoff to accept here — this chapter's
  closing tip box warns against reaching for the more sophisticated
  strategy "by default," but a checkout flow processing real payments is
  precisely the kind of genuinely high-stakes system where that added
  cost and complexity IS justified by the actual risk, rather than
  being reached for reflexively.

WHY THIS WORKS AS AN ANSWER
------------------------------
The deciding factor is matching the STRATEGY to the actual STAKES: this
scenario explicitly describes low blast-radius tolerance for a
high-consequence flow (real payments), which is exactly the profile
this chapter's table identifies canary (and blue-green) as being built
for — as opposed to rolling deployment's growing exposure, which fits
poorly with an explicit "can't tolerate broken exposure" requirement.