Girish
Ahirwar

Problem

• At on-sale time thousands of buyers compete for the same seats — a read-then-write check lets two buyers both see a seat as free and both win
• Clients retry on timeouts, so the same request can arrive twice and still has to count once
• Under overload the system must degrade into clean declines, never 5xx errors or wrong answers

Approach

• Atomic sale: one guarded conditional UPDATE (status='available' in the WHERE clause) under a Postgres row lock, rolled back unless every requested seat was taken — no read-then-write window
• Multi-seat requests are all-or-nothing, with seats locked in a global label order so overlapping requests can't deadlock
• Per-user limit made race-free with a transaction-scoped advisory lock on (show, user)
• Exactly-once retries: idempotency key stored under a unique constraint plus an advisory lock; a replay returns the original reservation, a reused key with different seats is a 409
• Opt-in time-boxed holds whose expiry is enforced in SQL against the database clock, so correctness never depends on a background sweeper
• Consistency over availability by design: one Postgres primary, readiness fails closed within 2s, and saturation is shed as 429 instead of guessing

Tools

Verification

• A one-command burst fires 20,000 requests — hot-seat storms, multi-seat pairs, and 10% same-key retries across 2,000 users — against a 500-seat show
• The run fails on any double-sold seat, any 5xx, or available + held + confirmed ≠ total seats, sampled every 500ms during the burst

Lessons learned

• Measure before blaming: failures I first pinned on Docker's port proxy turned out to be the app's own connection limits
• Failure paths need tests too: the readiness check hung during a database outage until a test exposed it, and now fails closed in 2s