Restaurant Table Booking System – Low Level Design Interview Practice
Practise the Restaurant Table Booking 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
Table allocation under contention: fitting parties to tables, and preventing two bookings landing on the same table for the same slot.
Requirements to establish first
- Search availability by restaurant, date, time slot and party size.
- Allocate a table that fits the party, preferring the smallest that does.
- Hold a slot briefly while the booking is completed.
- Support walk-ins and a waitlist when nothing is free.
- Cancel, and release the table back into the slot.
Core classes
- Restaurant – Its tables, its opening hours and its slot length.
- Table – Capacity and location. Not its schedule.
- TimeSlot – A table and an interval. Booking a table books a slot, not the table.
- Reservation – Customer, party size, slot, status.
- AllocationStrategy – Which table to give a party of four - smallest fit, window preference, or combining two tables.
- Waitlist – Ordered queue per restaurant, notified when a slot frees.
Design patterns that apply
- Strategy – Table allocation differs by restaurant: a bistro packs tightly, a fine-dining room leaves gaps. Keep it swappable.
- Observer – A cancellation notifies the waitlist without the cancel path knowing who is waiting.
- Singleton – The booking service, if you want one allocation authority per restaurant.
Follow-up questions to expect
- A party of six needs two tables of four joined. Does your model express a combined table?
- Two users book the last table in the same second. Show the lock, and say what happens to the loser.
- A party overstays its slot. Does the next booking fail, or does your slot model have slack?
Where candidates lose marks
- An isBooked flag on Table, which cannot represent a table free at 7pm and booked at 9pm.
- Allocating the largest free table, which empties your capacity for the next large party.
- No hold state, so a slow checkout lets two parties both believe they have the table.