Problem Statement & Context
What we are building and why it matters
Problem Statement & Context
The checkout flow turns a cart into a paid order. It collects address, shipping, taxes, promotions, and payment authorization, then commits the order with strong correctness and clear feedback. Checkout is the highest-risk path in commerce because it touches money, identity, and inventory in one transaction-like sequence.
What it must be
Fast (prevent abandonment); accurate (price, tax, shipping totals); idempotent (no double charges); fault-tolerant (safe to retry).
The journeys
- Guest: review cart → address → shipping → promo → taxes → pay → confirm.
- Logged-in: saved address + payment → shipping speed → authorize → place → receipt.
The load-bearing idea: a resumable, compensating saga over a frozen price snapshot
Checkout is not a single database transaction — it spans inventory, tax, fraud, payment, and order services that no shared transaction can wrap. So it is modeled as a durable state machine driven by a saga orchestrator: each step (validate address, quote shipping, calculate tax, reserve inventory, authorize payment, commit order, capture) is idempotent and its progress is persisted, so a crash can resume mid-checkout, a user can retry safely, and a failure compensates (void the auth, release the hold) instead of leaving money or stock stranded. Two more invariants complete the picture: authorize-then-capture (hold funds at checkout, move them only after the order commits, so a failed checkout is a void not a charge) and a frozen price snapshot (the total is signed at quote time so it cannot change between the moment the user agrees and the moment they pay). Resumable saga + authorize-then-capture + frozen snapshot is the whole design.
Scale anchors
50M checkouts/day (~580 rps avg, ~4,600 peak); 5–8× flash-sale spikes; ~1.3 payment attempts/checkout. These shape latency budgets, rate limits, and recovery.
Key Highlights
- •The checkout flow turns a cart into a paid order (address, shipping, taxes, promotions, payment authorization, order commit) — the HIGHEST-RISK path in commerce (money + identity + inventory in one transaction-like sequence); must be fast, accurate, idempotent, fault-tolerant
- •The load-bearing idea: checkout is NOT a single DB transaction (it spans inventory/tax/fraud/payment/order services no shared transaction can wrap) — it's a durable state machine driven by a SAGA orchestrator (idempotent persisted steps -> resume mid-checkout, retry safely, compensate on failure)
- •Two more invariants: authorize-then-capture (hold funds at checkout, move only after order commit -> a failed checkout is a VOID not a charge) + a frozen price SNAPSHOT (the total signed at quote time can't change between the user agreeing + paying)
- •Resumable saga + authorize-then-capture + frozen snapshot is the whole design; anchors 50M checkouts/day (~580 rps avg, ~4,600 peak), 5-8× spikes, ~1.3 payment attempts/checkout
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "Checkout is an orchestration problem across multiple services."
- "Idempotency protects against retries and double charges."
- "Latency budgets and correctness are equally important."