Restaurant Table Reservations: Availability Search and Conflict-Free Booking

Design a service that lets diners reserve tables at restaurants and lets restaurants manage those reservations. A diner searches for restaurants by location, date, time and party size, sees which time slots are open, books one, and can later change or cancel it. A restaurant configures its tables and seating hours, sees the bookings for each service, and marks parties as seated or as no-shows. The prompt is a single line, so treat the scope below as working assumptions and confirm them with the interviewer before you design. ### Constraints and Clarifications - Assume a consumer product covering many restaurants in many cities, where availability searches far outnumber completed bookings. - A table must never be confirmed to two parties for overlapping times; double-booking is the failure the design has to rule out. - Payments, reviews and menus are out of scope unless the interviewer brings them in. ### Clarifying Questions - Does a diner pick a specific table, or book a slot for a party size and let the system or the restaurant assign the table? - How long does a booking occupy a table: a fixed duration per party size, or whatever the restaurant configures? - Are deposits, cancellation fees or no-show penalties part of the product? - Should the service offer a waitlist when a slot is full, and how are walk-ins and phone bookings taken at the restaurant reflected? - Do some restaurants open new dates at a published time, so that demand for one restaurant spikes at that moment? ### Part 1 — Requirements, APIs and data model Pin down the functional and non-functional requirements for both diners and restaurants. Then define the main APIs and the data model for restaurants, tables, seating hours and reservations, and explain how you represent a table's availability over time. ```hint Model time as inventory Decide whether availability is stored as precomputed slots or derived from the bookings a table already has, and estimate what each choice costs when a restaurant edits its hours. ``` #### What This Part Should Cover - Functional scope for diners and restaurants, with explicit non-goals - Different consistency needs for browsing availability versus confirming a booking - APIs for search, booking, modification and cancellation, including safe retries - A data model in which the "one party per table at a time" rule can be enforced ### Part 2 — Confirming a booking without double-booking Walk through what happens from the moment a diner taps a time slot until they see a confirmation. Two diners may choose the last fitting table for the same slot at the same moment: show exactly where your design stops both from succeeding, and what happens if the client retries or loses its connection mid-request. ```hint Find the single point of truth Identify which component, and which write, actually decides who gets the table, and make sure nothing upstream of it can confirm a booking on its own. ``` #### What This Part Should Cover - The concurrency control that serializes competing bookings for the same table and time - Short-lived holds versus immediate confirmation, and how abandoned holds are released - Idempotent retries and recovery from partial failures, such as a committed booking whose confirmation message was never sent - How restaurant-side edits, such as closing a table or changing hours, interact with existing bookings ### Part 3 — Scaling search and absorbing booking spikes Most traffic is diners browsing availability across many restaurants. Explain how search stays fast and acceptably fresh. Then suppose one popular restaurant opens a new date and far more diners try to book than it has tables: describe how the system stays healthy and treats those diners fairly. ```hint Separate browsing from claiming Consider which reads can tolerate slightly stale availability, and where the cost of that staleness is finally paid. ``` #### What This Part Should Cover - An availability read path and how it is kept in sync with bookings - Partitioning that keeps one restaurant's hot spot from hurting the others - Admission control, fast rejection and abuse limits for a burst on a single restaurant - Asynchronous work such as confirmations, reminders and no-show handling ### What a Strong Answer Covers - The confirmation write is the only place correctness is enforced and is strongly consistent, while search is allowed to lag - Back-of-envelope sizing, labelled as assumptions, that justifies the storage and caching choices - Clear failure handling: retries, hold expiry, partial failures and database or cache outages - Trade-offs argued rather than asserted: slots versus intervals, holds versus direct booking, store choice - Observability: conflict rate, hold expiry, availability lag, and an audit that proves no table is double-booked ### Follow-up Questions - How would you add a waitlist that offers a freed table to the next diner without letting two of them claim it? - A large party needs two small tables pushed together. How does your availability model change? - How do you reconcile bookings the restaurant takes by phone with bookings made through your service? - How would you detect and limit bots that grab popular slots in order to resell them?