Design a ticket booking system. Which requirement drives the hardest part of the design?

Question

Accepted Answer

The hard requirement is: no seat may ever be sold twice. Everything else is routine.This single constraint eliminates most easy answers - you cannot use an eventually consistent store for seat state, and you cannot cache availability without a correctness story.Functional: browse events, view a seat map, hold a seat, pay, receive a ticket.The critical non-functional set:Strong consistency on seat state - forces a transactional store with row-level locking or conditional updates on the seat row.A hold with a TTL (typically 10 minutes) - seats must auto-release if payment is abandoned, which needs a reliable expiry mechanism rather than a nightly cleanup job.Extreme burst traffic - a popular release brings 100x normal load in one second, so you need a virtual waiting room or queue to level the load. Autoscaling cannot react in one second.Fairness - a queue position is a real requirement, not a nicety.The insight to voice: reads (browsing) are massive and cacheable; writes (holding a seat) are small in volume but must be strictly serialised per seat. So you split the paths entirely - a cached, slightly stale seat map for browsing, and a strongly consistent conditional write at the moment of the hold, where the user finds out for certain.

Design a ticket booking system. Which requirement drives the hardest part of the design?

Answer with Explanation