Ticket Booking Without Double-Booking
mediumOpen designVery commonly asked~45 minHLD roundBar raiserSDE-2 and upFlipkartRazorpayPhonePeAmazonSwiggyConsistency & ConsensusStorage & Data ModellingResilience
The question, as asked
“Design seat booking for something like BookMyShow or IRCTC. Two people tap the same seat at the same moment — what happens?”
Scope it before you design it
The prompt is vague on purpose. These are the clarifying questions a strong candidate asks first — answer them out loud before you touch the architecture.
- Assigned seats, or general admission? A seat map needs per-seat state and locking; a capacity counter is a very different, much easier problem.
- What's the peak? Tatkal, an IPL final or a big concert drop is a hundred-fold spike onto a single event — the system is sized for that minute, not the average day.
- Is a temporary hold part of the flow? Almost always yes — users need minutes to pay — and the hold, not the booking, is where the real concurrency design lives.
- How long is the hold, and what happens when it expires? Expiry is the part people forget, and it's where seats leak permanently.
- Can payment fail after the seat is held? Yes — so you need a compensating path, which makes this a distributed transaction question in disguise.
- Is overselling ever acceptable? For airlines, deliberately yes. For a cinema seat, never. This flips the entire consistency posture.
- Do users need to see live availability, or is a slightly stale seat map acceptable? Live updates for 100,000 concurrent viewers is its own system.
Your answer, first
Commit something before anything unlocks. Saved on this device as you go.
0 charactersExpand for room to draw
Framework hint
Sketch or write your approach above first. The hint gives you the structure, not the answer.