Design: E-Commerce Platform (Amazon-style)¶

Difficulty: Senior/Staff | Time: 60–90 minutes

1. Problem Statement¶

Design an e-commerce platform: users browse a product catalog, search, add items to a cart, check out, pay, and track their order to delivery. Think Amazon at small scale.

Most of this system is a read-heavy browse/search problem — similar in shape to other catalog- and feed-style exercises already on this site: index the catalog, cache aggressively, serve from replicas, done. That is not the hard part, and treating it as the centerpiece is a mid-level answer.

The hard part is one narrow, sharp problem: inventory correctness under concurrent purchase contention. A product has 1 unit left. Fifty people click "Buy Now" in the same second (a flash sale, a restock announcement, a doorbuster). Exactly one purchase must succeed. The other 49 must fail before a card is charged, not after. And the inverse failure mode is just as real: 200 people add that last unit to a cart and never check out — if you naively reserve stock on "add to cart," the item is now permanently unsellable even though nobody bought it.

This is the same shape of problem as the rate limiter — a shared mutable integer under concurrent writes — but the correctness bar is inverted. A rate limiter can admit 3% too many requests under a race and nobody notices. Inventory cannot oversell by even one unit without a real customer getting a cancellation email, a refund, and a reason to never order from you again. Approximate is not an option here.

Payment capture, idempotency keys, retry-safe charging, and PSP webhook handling are a solved problem on this site — see Payment Processing. This exercise assumes that system exists behind a POST /payments call and focuses on the part payment-processing.md doesn't cover: what has to be true about inventory before you're allowed to call it.

2. Clarifying Questions¶

3. Functional Requirements¶

• Browse and search the product catalog (filter by category, price, attributes)
• View product detail (price, stock status, images, description)
• Add/remove items in a cart; cart persists across sessions
• Checkout: reserve inventory, charge payment, create an order
• Track order status through fulfillment to delivery
• Cancel/return an order (restock inventory)

4. Non-Functional Requirements¶

5. Capacity Estimation¶

Catalog:
  10M SKUs, avg product doc 2 KB → ~20 GB searchable index
  Browse/search: 2M requests/day average, 5,000 rps peak (non-sale) → cache/CDN territory

Orders (steady state):
  500K orders/day → ~6 orders/second average, ~60/s at 10x peak

Flash sale / Black Friday — two different spikes, do not conflate them:
  Typical flash: 50–100× site-wide from ~6/s average → ~300–600 orders/s
  Named doorbuster (launch window, ~10 min): 50K orders/s site-wide — this is not 50–100×
  Single hot SKU: 5,000+ concurrent "buy" attempts against a stock count of, say, 200 units
  → 4,800 of those 5,000 requests MUST fail cleanly, fast, without touching payment

Inventory writes:
  Steady state: ~6 stock decrements/second, trivial for a single row
  Flash sale on one SKU: thousands of CAS attempts/second on ONE row — this is the number
  that breaks V1, not the site-wide aggregate

Cart:
  Assume 3x cart-creates per completed order (abandonment) → 1.5M cart events/day
  Cart data is small (product_id + qty), high write volume, short-to-medium lived

6. API Design¶

# Catalog (read-heavy, cacheable)
GET  /v1/products/search?q=...&category=...&page=...
GET  /v1/products/{product_id}
  → { id, title, price, stock_status: "in_stock"|"low_stock"|"out_of_stock", ... }
  # stock_status is a hint, not a guarantee — always re-checked at reservation time

# Cart
POST   /v1/cart/items          { product_id, quantity }
DELETE /v1/cart/items/{id}
GET    /v1/cart

# Checkout — the section that matters
POST /v1/checkout/begin
  { cart_id }
  → { checkout_id, reserved_items: [...], expires_at }   # 201, or 409 if any item can't be reserved
POST /v1/checkout/{checkout_id}/confirm
  { payment_method }
  → { order_id, status: "confirmed" }                    # 200, or 402 payment_failed, 410 reservation_expired

# Orders
GET /v1/orders/{order_id}
  → { order_id, status: "placed"|"paid"|"picking"|"packed"|"shipped"|"delivered"|"cancelled", tracking }

7. Data Model¶

Three stores with different consistency needs — do not put them in the same table, or worse, the same row.

-- Catalog: search-optimized, denormalized, eventually consistent from a source-of-truth
-- In practice this is an Elasticsearch/OpenSearch document, not a normalized SQL table.
CREATE TABLE products (            -- source of truth; indexed async into search
    id            UUID PRIMARY KEY,
    title         TEXT NOT NULL,
    description   TEXT,
    price_cents   INT NOT NULL,
    category_id   UUID,
    attributes    JSONB,           -- size, color, etc.
    updated_at    TIMESTAMPTZ
);

-- Inventory: the correctness-critical table. A raw counter is not enough —
-- reservations need to be visible and expirable, separate from committed sales.
CREATE TABLE inventory (
    product_id       UUID PRIMARY KEY,
    on_hand          INT NOT NULL,           -- physically in the warehouse
    reserved         INT NOT NULL DEFAULT 0, -- held by in-flight checkouts
    available        INT GENERATED ALWAYS AS (on_hand - reserved) STORED,
    version          INT NOT NULL DEFAULT 0, -- optimistic lock / CAS
    updated_at       TIMESTAMPTZ
);

CREATE TABLE inventory_reservations (
    id            UUID PRIMARY KEY,
    product_id    UUID NOT NULL REFERENCES inventory(product_id),
    checkout_id   UUID NOT NULL,
    quantity      INT NOT NULL,
    expires_at    TIMESTAMPTZ NOT NULL,      -- TTL: auto-release if checkout never confirms
    status        VARCHAR(16) NOT NULL,      -- held | payment_pending | committed | released
                                              -- sweeper only ever touches 'held' — 'payment_pending' is
                                              -- deliberately excluded so a slow payment call can never race the TTL
    INDEX idx_expiry (status, expires_at),   -- sweeper scans this, not the whole table
    INDEX idx_checkout (checkout_id, status) -- confirm_checkout claims/commits every row for a checkout together
);

-- Written before the payment gateway is ever called; see §13's crash-recovery discussion.
CREATE TABLE payment_intents (
    idempotency_key  VARCHAR(64) PRIMARY KEY,  -- "checkout:{checkout_id}"
    checkout_id      UUID NOT NULL,
    status           VARCHAR(16) NOT NULL,     -- initiated | succeeded | failed
    payment_id       VARCHAR(64),              -- set once the gateway responds
    created_at       TIMESTAMPTZ NOT NULL,
    INDEX idx_stuck (status, created_at)       -- reconciler scans "initiated past a timeout"
);

-- Orders: state machine, append-only status history for auditability
CREATE TABLE orders (
    id            UUID PRIMARY KEY,
    user_id       UUID NOT NULL,
    status        VARCHAR(16) NOT NULL,  -- placed -> paid -> picking -> packed -> shipped -> delivered
                                          --        -> cancelled (from placed/paid only)
    total_cents   INT NOT NULL,
    payment_id    VARCHAR(64),           -- FK into payment-processing.md's system
    created_at    TIMESTAMPTZ,
    INDEX idx_user_created (user_id, created_at)
);

CREATE TABLE order_status_history (
    order_id      UUID NOT NULL,
    status        VARCHAR(16) NOT NULL,
    ts            TIMESTAMPTZ NOT NULL
);

8. Version 1 — simplest thing that works¶

Single Postgres instance, synchronous checkout, no separate reservation step. Good enough until you have real concurrent contention on a single SKU.

graph LR
    Client -->|browse| API[API process]
    API -->|search| PG[(Postgres)]
    Client -->|checkout| API
    API -->|"UPDATE inventory SET stock=stock-1 WHERE id=? AND stock>0"| PG
    API -->|charge| Pay[Payment service]

def checkout(product_id: str, qty: int, payment_method) -> Order:
    with db.transaction():
        # Atomic compare-and-set in one statement — the row lock IS the concurrency control
        updated = db.execute(
            "UPDATE inventory SET stock = stock - %s WHERE product_id = %s AND stock >= %s",
            qty, product_id, qty
        )
        if updated.rowcount == 0:
            raise OutOfStock()

        # Still inside the DB transaction: charge synchronously
        payment = payment_service.charge(payment_method, amount)  # see payment-processing.md
        if not payment.success:
            raise DBRollback()  # the UPDATE above rolls back, stock is restored

        order = db.insert_order(product_id, qty, payment.id, status="paid")
    return order

This correctly prevents overselling — the WHERE stock >= qty guard makes the decrement atomic and self-checking. Ship it for a catalog with no flash-sale traffic. Then find the actual bottleneck.

9. Identify the bottleneck¶

10. Version 2 — reservation with TTL, contention isolated from payment¶

Split checkout into begin (reserve, fast, no external call) and confirm (charge, then commit the reservation). A sweeper releases expired holds.

graph LR
    Client -->|checkout/begin| API[API]
    API -->|"CAS: reserved += qty\nWHERE available >= qty"| INV[(Inventory table)]
    API -->|insert hold, expires_at=now+10min| RES[(Reservations)]
    Client -->|checkout/confirm| API
    API -->|"CAS: ALL rows WHERE checkout_id\nstatus held→payment_pending"| RES
    API -->|"insert payment_intents\nstatus=initiated, BEFORE charging"| PI[(Payment intents)]
    API -->|charge, idempotency_key=checkout_id| Pay[Payment service]
    Pay -->|success| API
    API -->|"CAS: ALL rows WHERE checkout_id\nstatus payment_pending→committed"| RES
    API -->|"on_hand -= qty, reserved -= qty per item"| INV
    Sweeper[Reservation sweeper\nruns every few seconds] -->|"CAS per row: held→released\nonly if rowcount=1, then reserved -= qty"| RES
    Reconciler[Payment intent reconciler] -->|"status=initiated past timeout\n→ re-query/retry gateway"| PI

def begin_checkout(cart_id: str) -> Checkout:
    # checkout_id is shared across every line item's reservation row — id remains each row's own
    # primary key (inventory_reservations.id), so a cart with 3 items produces 3 rows, all claimed
    # and committed together in confirm_checkout via WHERE checkout_id = %s, never WHERE id = %s.
    checkout_id = new_id()
    holds = []
    with db.transaction():
        for item in cart_items(cart_id):
            updated = db.execute(
                """UPDATE inventory SET reserved = reserved + %s
                   WHERE product_id = %s AND (on_hand - reserved) >= %s""",
                item.qty, item.product_id, item.qty
            )
            if updated.rowcount == 0:
                raise OutOfStock(item.product_id)   # rolls back holds taken so far in this txn
            db.insert_reservation(new_id(), checkout_id, item.product_id, item.qty,
                                   expires_at=now() + timedelta(minutes=10), status="held")
            holds.append(item)
    return Checkout(checkout_id, holds, expires_at=...)

def confirm_checkout(checkout_id: str, payment_method) -> Order:
    # Step 1: atomically claim EVERY reservation row for this checkout out of the sweeper's reach
    # before charging anything. Checking `expired` and then charging leaves a window where the
    # sweeper's TTL scan (WHERE status='held') can release a hold WHILE the payment call is in
    # flight; moving straight to 'payment_pending' — a status the sweeper's query never matches —
    # closes that window instead of just narrowing it. The rowcount check makes this all-or-nothing
    # across a multi-item cart: if any line's reservation already expired or was already claimed by
    # a concurrent confirm, none of them move to payment_pending.
    with db.transaction():
        items = db.query("SELECT * FROM inventory_reservations WHERE checkout_id = %s", checkout_id)
        claimed = db.execute(
            """UPDATE inventory_reservations SET status = 'payment_pending'
               WHERE checkout_id = %s AND status = 'held' AND expires_at > now()""",
            checkout_id
        )
        if claimed.rowcount != len(items):
            raise ReservationExpired()  # rolls back the whole claim — fail BEFORE charging, never charge for a partial cart
        reservations = db.query("SELECT * FROM inventory_reservations WHERE checkout_id = %s", checkout_id)
        total = sum(r.quantity * price_of(r.product_id) for r in reservations)

        # Durable idempotency record, written in the SAME transaction as the claim above and BEFORE
        # the gateway is ever called — this is what makes the reconciler in §13 possible. Without this
        # row, a crash between "gateway charged" and "any local write" is unrecoverable by definition;
        # with it, the reconciler always has something to scan even if this process never wakes up again.
        db.execute(
            """INSERT INTO payment_intents (idempotency_key, checkout_id, status, created_at)
               VALUES (%s, %s, 'initiated', now())""",
            f"checkout:{checkout_id}", checkout_id
        )

    # Charge OUTSIDE any inventory lock. Idempotency key is derived from checkout_id, not minted
    # fresh — a client retry (or a retry after a timeout where the first charge actually succeeded)
    # hits the payment gateway's dedup path instead of double-charging. See payment-processing.md.
    payment = payment_service.charge(payment_method, total, idempotency_key=f"checkout:{checkout_id}")
    db.execute(
        "UPDATE payment_intents SET status = %s, payment_id = %s WHERE idempotency_key = %s",
        "succeeded" if payment.success else "failed", payment.id, f"checkout:{checkout_id}"
    )

    if not payment.success:
        # Revert every claimed row to 'held' so the customer can retry confirm before the original
        # TTL — do NOT leave them stuck in 'payment_pending' (unsweepable forever) or silently drop
        # back to 'held' with a stale expires_at that's already passed; extend slightly if it has.
        db.execute(
            """UPDATE inventory_reservations SET status = 'held', expires_at = GREATEST(expires_at, now() + interval '2 minutes')
               WHERE checkout_id = %s AND status = 'payment_pending'""",
            checkout_id
        )
        raise PaymentFailed()

    with db.transaction():
        committed = db.execute(
            """UPDATE inventory_reservations SET status = 'committed'
               WHERE checkout_id = %s AND status = 'payment_pending'""",
            checkout_id
        )
        if committed.rowcount != len(reservations):
            # Should be unreachable — 'payment_pending' is never swept and only this function transitions
            # it — but treat it as a hard invariant violation, not a silent double-decrement: refuse to
            # touch inventory and hand off to the compensation path (refund; see §13).
            raise ReservationCommitConflict(payment_id=payment.id)
        for r in reservations:
            db.execute("""UPDATE inventory SET on_hand = on_hand - %s, reserved = reserved - %s
                           WHERE product_id = %s""", r.quantity, r.quantity, r.product_id)
        order = db.insert_order(checkout_id, reservations, payment.id, status="paid")
    return order

def sweep_expired_reservations():
    # status='held' only — 'payment_pending' is excluded by construction, so a reservation currently
    # mid-charge is never at risk of being released out from under an in-flight payment. But between
    # the SELECT below and the release, confirm_checkout could still win the held -> payment_pending
    # race on a row this sweeper already read — so the release itself must be a conditional CAS, not
    # an unconditional write, and inventory is only touched if that CAS actually took effect.
    candidates = db.query(
        "SELECT id, product_id, quantity FROM inventory_reservations "
        "WHERE status='held' AND expires_at < now() LIMIT 1000"
    )
    for r in candidates:
        with db.transaction():
            released = db.execute(
                "UPDATE inventory_reservations SET status='released' WHERE id=%s AND status='held'",
                r.id
            )
            if released.rowcount == 1:   # we actually won the race for this row
                db.execute("UPDATE inventory SET reserved = reserved - %s WHERE product_id = %s",
                           r.quantity, r.product_id)
            # rowcount == 0 means confirm_checkout claimed it first (held -> payment_pending) between
            # the SELECT and here — do nothing; that reservation is no longer this sweeper's problem

The conditional WHERE id=%s AND status='held' is what makes this safe against confirm_checkout — it's what actually closes the race, not the initial SELECT. Running multiple sweeper replicas in parallel is also safe because of it (two replicas racing the same row just means one gets rowcount=1 and the other gets rowcount=0), but it's still wasted work for two replicas to select and attempt the same 1,000 candidate rows every cycle — select with FOR UPDATE SKIP LOCKED so concurrent sweeper instances each pull a disjoint batch instead of colliding on every row.

This is the same "shared mutable integer under contention" shape as the rate limiter's token bucket — many writers, one hot counter, atomic compare-and-set. The difference is the failure direction: a rate limiter that occasionally over-admits is a minor UX blip; inventory that oversells by one unit is a broken promise to a customer. You cannot approximate your way out of this one with a locally-cached slice the way the rate limiter's V3 does.

For the single hottest SKU in a flash sale, front the reservation write with a queue or admission gate (conceptually the rate limiter again): let requests past a coarse per-second cap reach the inventory row at all, and 429/queue the rest instead of letting 5,000 requests pile up on one row lock simultaneously.

11. Identify the next bottleneck¶

12. Version 3 — production architecture¶

graph TD
    Client --> CDN[CDN / edge cache\ncatalog pages]
    Client --> GW[API Gateway]
    GW -->|search/browse| Cat[Catalog Service\neventually consistent]
    Cat --> Search[(Search index\nElasticsearch)]
    Search -.->|async index| CatDB[(Product DB, source of truth)]
    GW -->|cart ops| Cart[Cart Service]
    Cart --> CartDB[(Cart store, Redis)]
    GW -->|checkout begin| Orch[Checkout Orchestrator\nsaga coordinator]
    Orch -->|admission gate, hot SKUs only| RL[Rate limiter / queue\nsee rate-limiter.md]
    RL --> Inv[Inventory Service\nstrongly consistent, sharded by product_id]
    Inv --> InvDB[(Inventory + reservations\nsharded Postgres)]
    Sweeper[Reservation sweeper\nSLO-bound lag] --> InvDB
    Orch -->|checkout confirm| Pay[Payment Service\nsee payment-processing.md]
    Pay -->|success/fail| Orch
    Orch -->|commit reservation, create order| OrderDB[(Order Service DB\nstate machine)]
    Orch -->|order.placed event| Bus[Event bus]
    Bus --> Fulfill[Fulfillment Service]
    Fulfill --> WMS[Warehouse Management System\npick/pack/ship]
    WMS -->|status updates| Bus
    Bus --> OrderDB
    Bus --> Notify[Notifications]

Key production decisions:

• Catalog and inventory are different services with different consistency models, deliberately. Catalog reads from a search index that lags the source of truth by seconds — fine, because a stale description or a "low stock" badge that's slightly wrong causes no harm. Inventory reads from the strongly-consistent, sharded-by-product service every single time at checkout, never from a cache, because that's the one number that must never lie.
• Checkout is a saga, not a distributed transaction, because it spans three independently-owned systems (inventory hold → payment charge → order creation → fulfillment kickoff) that cannot share a database transaction. See Sagas for the orchestration/choreography trade-off and compensation pattern; here the compensation for "payment failed after reservation" is simply letting the TTL expire (or releasing it immediately), and the compensation for "fulfillment can't actually pick the item" (rare, but warehouses drift) is a refund + cancellation, not a rollback of the payment system.
• The admission gate sits in front of inventory, not payment. Rate-limit or queue at the reservation step for hot SKUs specifically — a virtual waiting room for a doorbuster — so the inventory row never sees more simultaneous writers than it can serialize through cleanly, and customers who are turned away never reach the payment gateway at all (protects payment-processing.md's system from load it shouldn't have to absorb either).
• Inventory is sharded by product_id. There is no cross-shard transaction needed for a single-item checkout; multi-item carts reserve each item's shard independently within the saga, and a partial reservation failure releases whatever succeeded (compensation, not rollback).
• Fulfillment is async and event-driven. order.placed triggers picking; the warehouse system publishes its own state transitions back onto the bus, and the order's status is a read model built from that stream, not something the checkout path blocks on.

13. Failure analysis¶

14. Consistency considerations¶

• Inventory must be strongly consistent; catalog does not need to be. The reason isn't dogma — it's what each number is used for. Catalog data (title, description, price display, "in stock" badge) informs a decision the customer is about to make; being seconds stale costs nothing because the real check happens at reservation time regardless. Inventory's available count is the thing that is the decision — if it's stale, you either oversell (customer harm) or falsely show sold-out (revenue loss). Different blast radius, different consistency budget.
• The reservation-hold pattern is how you avoid a distributed transaction across "check stock" and "charge card." You cannot open one ACID transaction spanning your database and a third-party payment gateway. Reservation with TTL is the bridge: reserve (fast, local, strongly consistent) → charge (slow, external, no lock held) → commit (fast, local). If the middle step fails or never happens, the TTL is the safety net that returns stock to the pool — this is a saga's compensating action, applied at the smallest possible scope.
• Read-your-writes matters for the customer's own order status, not for other customers' view of stock. After checkout, the buyer must immediately see "order placed" — route that read to the primary or return the order object directly from the confirm response rather than making the client re-fetch through a replica that might lag.
• Multi-item cart checkout is not one atomic operation across items. Reserving item A and item B in the same cart are two separate shard-local transactions; a partial success (A reserved, B out of stock) needs an explicit compensation (release A's hold) rather than an assumption that "the transaction" covers both.

15. Observability¶

Catalog:
  search_latency_p50/p99
  cache_hit_rate{layer=cdn|search_cache}
  index_lag_seconds (product DB -> search index)

Inventory (the metrics that actually page someone):
  reservation_conflict_rate{product_id}        -- CAS failures per SKU, spikes = contention
  reservation_hold_duration histogram
  reservation_sweeper_lag_seconds              -- alert > 60s during any sale event
  inventory_available_vs_on_hand_delta{product_id}  -- catches the "false sold out" pattern
  hot_sku_admission_gate_reject_rate

Checkout / orders:
  checkout_begin_to_confirm_latency_p99
  checkout_abandon_rate (begin without confirm within TTL)
  saga_compensation_count{reason}
  order_state_transition_lag{from,to}          -- e.g. paid -> picking taking too long

Alerts:
  reservation_sweeper_lag > 60s
  reservation_conflict_rate > threshold on any single SKU (flash-sale detector)
  available_inventory dropping to 0 while on_hand > 0 for > 5 min (sweeper-lag proxy)
  saga_compensation_count spike (fulfillment or payment desync)

16. Cost analysis¶

Search index (Elasticsearch, 10M docs, ~20GB + replicas):     ~$600/month
Product DB (Postgres, source of truth, small rows):           ~$200/month
Inventory service (sharded Postgres, low volume, high value): ~$400/month (over-provisioned for burst, not steady state)
Cart store (Redis):                                            ~$150/month
CDN (catalog pages, high cache-hit):                            ~$300/month
Order DB + event bus (Kafka/SNS-SQS):                           ~$500/month
Flash-sale burst capacity (autoscaled inventory/checkout pods, reserved but idle 355 days/year): ~$300/month amortized
Total:                                                          ~$2,450/month

Cost lever: the inventory service is deliberately over-provisioned relative to its
steady-state load (§5: ~6 writes/sec normally) because its cost driver is peak
contention-handling capacity, not average throughput — sizing it for the average
is exactly the mistake that oversells during a sale.

17. Alternative architectures¶

18. Staff Engineer Extensions¶

19. Interview follow-ups¶

1. "Why not just use a single SELECT FOR UPDATE and hold the row lock through the payment call?" — Because the payment gateway's latency (hundreds of ms to seconds) becomes your row's lock duration. At flash-sale concurrency that serializes thousands of requests through an external network call, which is the exact bottleneck §9 identifies. Splitting reserve/charge/commit gets the external call outside any database lock.
2. "How is the cart different from a reservation?" — By default, nothing in the cart reserves stock; it's a wishlist. Reservation happens at checkout/begin, deliberately late and short-lived, specifically to avoid the "abandoned cart locks the last unit forever" failure mode. If product asks for "reserve at add-to-cart" (some retailers do, for high-demand items), that's a valid requirement — but it means the TTL and sweeper need to be tuned much more aggressively, since cart dwell time is far longer than checkout dwell time.
3. "What happens to inventory correctness if the reservation service and the order service are eventually consistent with each other?" — This is the saga's job, not a shared-database job. The reservation commit and the order-row insert happen in one local transaction (same service, same DB) specifically so they can't drift from each other; the order service publishing order.placed to fulfillment is where eventual consistency is acceptable, because fulfillment lagging by a few seconds costs nothing, while inventory and its own order record disagreeing costs money.
4. "How would you test the overselling guarantee before a real sale?" — Load test the exact contention shape: N concurrent workers hitting checkout/begin against one SKU with stock = K, assert exactly K succeed and N-K get a clean 409, not a 500 or a silent double-reserve. Run it against a stock count of 1 as the sharpest case. This is a correctness test, not a performance test — it should be in CI, not just a pre-launch fire drill.

Self-Assessment¶

• [ ] I can explain why catalog is eventually consistent and inventory is strongly consistent, with a reason tied to what each number is used for
• [ ] I can describe the reservation-with-TTL pattern and why it replaces a distributed transaction across "check stock" and "charge card"
• [ ] I can name both inventory failure modes — overselling AND permanently-locked reserved stock — and the mechanism that prevents each
• [ ] I can explain why the row-lock bottleneck at flash-sale scale is about contention on one row, not aggregate site traffic
• [ ] I can distinguish this exercise's checkout saga from payment-processing.md's idempotency mechanism and say where each one's responsibility starts and ends