Flash sale inventory

Business constraint

Limited stock, huge spike. Oversell is unacceptable. Checkout latency still has a budget.

Naive v0

Read stock, decide, write stock without atomicity. Or long transactions around payment.

Failure drill

Oversell under concurrency. Inventory locked for abandoned carts. Payment timeouts hold stock forever.

Evolution path

Iteration 1

Atomic reserve that decrements only if remaining ≥ n (lab flash-sale). Reservation holds a lease TTL.

Iteration 2

Commit converts reservation → sold; expiry releases. Idempotent reserve keys per cart.

Iteration 3

Optional shard inventory for extreme hot SKUs; reconcile carefully.

Implementation cut

Separate reserve from pay. Never hold DB locks across payment RPCs. Load-test oversell attempts.

Numbers

Oversell count = 0 in soak. Reservation expiry lag. Checkout p99 under spike.

Pattern tags

• optimistic-version
• lease-fencing

Self-check

1. Why read-then-write fails?
2. What does a reservation TTL prevent?
3. Why not lock across payment?
4. How do idempotency keys help?
5. When do you shard a SKU?

Walkthrough

Recordings will appear here when published. Until then, work the failure drill and lab locally — pause after each iteration and write the metric that moved.

Lab package: see /systems/labs/flash-sale/.