Design a Restaurant Seat and Table Reservation System

Design a reservation system for restaurant seating. Diners search a restaurant's availability for a party size, date and time, book a slot, and can later change or cancel the booking. Restaurant staff configure their tables and opening hours, see the day's bookings, and seat walk-in guests at the same tables. The system must show diners useful availability quickly, and it must never give the same table to two parties for overlapping times, even when several diners try to book the last suitable table at the same moment. ```hint Define the unit of inventory Before drawing any services, decide exactly what a booking consumes: a seat count, a table, or a table for a stretch of time. The double-booking guarantee is built on that choice. ``` ```hint Who gets to say no Two diners press "book" for the last suitable table at the same instant. Decide which component has the final say, and how it turns one of them away. ``` ```hint Searching is not booking Availability is read far more often than it is booked. Consider whether the search path and the booking path need the same freshness. ``` ### Constraints and Clarifications - Assume a booking is for a party size at a start time, and occupies a table for a seating duration that the restaurant configures. - Walk-ins and bookings that staff enter by hand use the same tables as online bookings. ### Clarifying Questions - Is this a booking tool for one restaurant or a platform for many restaurants, and roughly how many bookings and searches per day should it handle? - Does a diner reserve a specific table or seat, or only a party size and time, with the restaurant assigning the table? - How long does a seating last, and does that depend on party size or time of day? - Can large parties be seated by combining tables? - Are deposits or no-show fees required, and what is the cancellation policy? - May a restaurant overbook to offset no-shows? ### What a Strong Answer Covers - An explicit inventory model (tables over time) and the exact rule that defines a conflict - A double-booking guarantee enforced by the source of truth, with the race it prevents spelled out - A fast, possibly stale availability read path, separated from an authoritative booking write path - Short-lived holds, idempotent confirmation, and cancellations that release inventory - Partitioning by restaurant, and a plan for popular restaurants when many diners book at once - Time zones, confirmations and reminders, and the restaurant staff's view of the day ### Follow-up Questions - A popular restaurant opens bookings for a whole month at a fixed time, and thousands of diners book at once. What changes? - How would you seat a large party by combining tables without blocking more tables than needed? - A restaurant removes a table from its floor plan while future bookings are assigned to it. How should the system react? - How would you add a deposit without charging a diner twice when the client retries?