BookMyShow System – Low Level Design Interview Practice
Practise the BookMyShow System low level design problem the way an LLD round actually runs. You are asked for requirements first, then a class model, and then to extend the design when a new requirement lands part way through – the follow-up that separates a design that was memorised from one that was understood.
The round checks the things interviewers grade: whether your classes carry single responsibilities, whether you reached for a design pattern or reinvented one, whether the design absorbs a new requirement without rewriting what exists, and whether you can explain a trade-off out loud. Feedback covers class modelling, SOLID principles, use of patterns, extensibility and communication.
What this question is really testing
Seat locking. The class model takes ten minutes; the rest of the round is the race between two users on the same seat and the lifecycle of an unpaid hold.
Requirements to establish first
- Browse cities, cinemas, movies and showtimes.
- Display a seat map for a show with its seat types and prices.
- Lock selected seats for a short window while payment is attempted.
- Confirm on payment, release on timeout or failure.
- Cancel with a refund rule that depends on how close to showtime it is.
Core classes
- Movie / Cinema / Screen – The catalogue and the physical rooms.
- Show – A movie on a screen at a time. Seat state attaches here, not to the screen.
- Seat / ShowSeat – The physical seat, and its state for one show: available, locked until T, booked.
- SeatLockProvider – Acquires and expires locks. The single most discussed class in this question.
- Booking – User, show, seats, status, payment reference.
- PricingStrategy – Seat type, show time and day of week.
Design patterns that apply
- State – Booking moves through created, locked, confirmed, expired, cancelled, and most of those transitions are one-way.
- Strategy – Pricing by seat class and show timing; weekend and recliner rates are two axes, not one.
- Observer – Lock expiry notifies the booking to release its seats.
Follow-up questions to expect
- Two users select seat F7 at the same instant. Show the lock. Is it in memory, in the database, or in a distributed store - and what breaks when there are two app servers?
- A lock expires after payment succeeded but before confirmation was written. Which wins?
- Should the lock timeout be fixed, or longer for a larger party? Defend either answer.
Where candidates lose marks
- A single isBooked flag, which has no way to represent "held by someone mid-payment".
- Attaching seat state to Screen rather than Show, so booking one show books every show.
- Saying "use a transaction" without stating what is locked and for how long.