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.

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.

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.

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