← Back to problems

22. Ticketing System with Inventory Contention

EXPERT
ConcurrencyInventoryMessage QueueRate LimiterSystem Design

Design a ticketing system where limited inventory is sold under extreme concurrent demand (flash sales), preventing oversell while absorbing enormous read and reservation load.

Design a ticketing/inventory system for high-demand events where a fixed, limited inventory (seats, tickets) is sold under sudden extreme concurrency : a flash sale where far more buyers arrive simultaneously than there are tickets. The defining correctness requirement is no oversell: the system must never sell the same seat twice or sell more tickets than exist, even when tens of thousands of buyers contend for the last few hundred tickets in the same second. The defining scale requirement is absorbing that thundering-herd load : a huge burst of browse, reserve, and purchase requests : without collapsing. These two pressures conflict: correctness under contention pushes toward serialized, transactional writes on the inventory record, while scale pushes toward caching, admission control, and queueing to keep the stampede off that contended record. Your design must reconcile them: rate-limit / admit the incoming flood, cache the read-heavy browse path, funnel reservation/purchase through a mechanism that serializes access to the authoritative inventory count, and hold the database as the transactional source of truth for what's actually sold. Design the architecture emphasizing admission control, read caching, a serialization path to the inventory, and the transactional store. Then document the storage/consistency model, the trade-offs (reservation holds, oversell vs. availability, queue-based fairness), and the security/abuse concerns (bots, scalping) of a flash sale.
Log in to submit a solution

Comments

Log into join the discussion.