Katkat
Back

Design a Restaurant Seat and Table Reservation System

ToastSoftware Engineer · Technical Screen
HardSoftware EngineerTechnical ScreenSystem Design

Last updated

A system design question asking for a restaurant seat reservation system in which diners search availability by party size and time, then book, change or cancel. It tests the table-and-time inventory model, preventing double booking under concurrent requests, holds, availability caching and partitioning by restaurant.

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.

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?

Hints

Hint 1

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 2

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 3

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.

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?