Sell a limited drop without overselling
Separate reservation, payment and confirmed purchase during a 50,000-person launch.
Backend and product engineers designing software behavior.
Your approach: Use diagrams, tables or prose for customer contracts, state transitions and data ownership; include APIs only to the depth the question requests.
The problem
Design checkout for a drop of 2,000 individually sellable items. A product manager wants a countdown reservation, a trustworthy order confirmation and a waitlist when inventory is exhausted.
- 50,000 customers may arrive within a minute, but only 2,000 items exist.
- The payment provider can send duplicated or out-of-order webhooks; a timed-out charge can later succeed.
- A user can retry checkout from two devices. Product policy permits one item per customer.
Work within these constraints
Declare the reservation window offered to a customer; it must not exceed five minutes.
Required target: ≤ 300 seconds
Confirmed allocations must never exceed available inventory; distinguish an authorization from a captured payment.
Enforce the policy across concurrent requests and retries.
Define the customer outcome and compensation when a payment succeeds after a reservation expires.
What to deliver
Customer and API contract
Specify reserve, pay, confirm and status behavior, including idempotency keys and honest pending states.
Data and state machine
Show reservation/order/payment states, inventory ownership and the atomic transition that prevents oversell.
Race walkthrough
Trace expiry racing with a delayed successful payment and two-device retries.
Load and admission
Estimate burst load, protect the invariant under overload and explain fair-enough admission or its limitations.
Product tradeoff
Compare holding inventory before payment with allocating after payment, including the customer experience.