Design a restaurant reservation system

Quick Overview

This question evaluates skills in system architecture and engineering, including data modeling, API design, concurrency control to prevent double-booking, availability and scheduling logic, scalability under traffic spikes, and operational concerns like auditability and low-latency queries.

Problem

Design a restaurant reservation system similar to common booking products.

The system should allow customers to search availability and book tables at a restaurant, and allow the restaurant to manage tables and reservations.

Core requirements

Customer-facing

View a restaurant’s availability for a given date/time and party size.
Create a reservation (name/contact, party size, desired time, special notes).
Modify/cancel a reservation.
Receive confirmation and reminders (email/SMS/push).

Restaurant-facing

CRUD restaurants, operating hours, blackout dates/holidays.
Configure table inventory (table IDs, capacities, combinable tables).
View upcoming reservations; mark no-shows/seated/completed.

Non-functional requirements

Prevent double-booking (correctness is critical).
Low latency for availability lookup (e.g., p95 < 200–300ms).
Handle spikes (e.g., lunch/dinner hours, popular restaurants).
Auditability (who changed/cancelled what) and idempotent APIs.

Assumptions (state clearly)

Multi-restaurant platform (many restaurants).
Reservations are time-bound (e.g., 90-minute default duration, configurable).
Timezone-aware scheduling.

What to cover in your design

Data model (tables/reservations/locks/slots).
APIs and main flows (search availability → book → confirm → remind).
Concurrency control strategy to avoid double-booking.
Scaling approach and caching strategy.
Edge cases: cancellations, no-shows, walk-ins, table combinations, overbooking/waitlist.

Design a restaurant reservation system

Quick Overview