BookMyShow Mock Interview – Practise the Ticket Booking Design Round

A mock interview round: design BookMyShow out loud while the interviewer pushes on seat locking, concurrent booking and payment timeouts.

This is a full mock interview round, not a written solution to read through. The AI interviewer poses the Ticket Booking design problem, pushes back on your choices, and asks the follow-up questions a real interviewer would: how the system behaves as traffic grows, where the bottlenecks move, which consistency guarantees you are trading away, and what happens when a component fails. You get structured feedback and a score on requirement gathering, high level architecture, data modelling, scalability and communication at the end of every attempt.

Designing Ticket Booking is a recurring question in High Level Design (HLD) rounds at Google, Amazon, Meta, Microsoft, Netflix and Uber, and at high-growth product companies hiring SDE-2 and above. Working through it out loud - repeatedly, under time pressure - is what separates candidates who know the components from candidates who can defend a design.

What this question is really testing

Seat-level concurrency under a demand spike that is both extreme and scheduled - everybody arrives in the same second.

Scale to establish before drawing anything

A popular event: 100,000 seats, 1M users arriving within a minute of sale opening.
Normal load is trivial; the design exists entirely for the spike.
Seat state per show is small enough to hold in memory, which is what makes locking feasible.

Core components

Virtual waiting room – Admits users to the purchase path at a controlled rate. The spike is shaped here or it is not shaped at all.
Seat inventory service – Per-show seat state with atomic lock acquisition and a TTL.
Lock manager – Holds a seat for a few minutes while payment runs. Expiry must be automatic, not a cleanup job.
Booking service – Confirms on payment success, releases on failure or timeout.
Payment integration – Asynchronous and idempotent, because this is where the lock window is spent.

Trade-offs to defend

Lock duration – Too short and slow payers lose seats they are paying for; too long and inventory looks sold out while nothing has sold. Pick a number and justify it.
Waiting room versus raw queueing – A waiting room gives a fair, visible experience and adds a component. Letting everyone through and failing most of them is cheaper and worse.
Hold seats or hold a count – Reserved seating needs seat-level locks; general admission only needs a counter, which is far cheaper. Know which you are designing.

Follow-up questions to expect

A lock expires one second after payment authorises. Who owns the seat?
Two users select the same seat at the same millisecond. Show the atomic operation.
Sale opens and 1M users hit the page. What is the first thing that falls over?