Design a Restaurant Booking Service

Reference Answer

For a full example answer with detailed architecture diagrams and deep dives, see our Design Yelp guide. While the Yelp guide focuses on business discovery and reviews, many of the same patterns around geo-search, real-time availability, and handling contention on scarce inventory apply directly to a restaurant reservation system.

Also review the Search and Databases building blocks for background on geo-spatial indexing and transactional storage.

Problem Statement

Design a restaurant booking system that allows users to search for restaurants by name, cuisine, or location (defaulting to 30 miles radius), and make, edit, or cancel individual or group reservations.

A restaurant booking service is an online platform (think OpenTable or Yelp Reservations) where diners search by name, cuisine, or location and reserve a table for a specific time and party size. It must default to a 30-mile radius for location searches, surface near real-time availability, and let users edit or cancel reservations.

Interviewers ask this because it combines three classic system design challenges: high-read geo/text search, hot-spot contention on scarce inventory (Friday 7pm tables), and end-to-end workflows for holds, confirmations, edits, and cancellations. It tests whether you can balance correctness and availability, apply the right data models and indexes, and reason about real-time updates and eventual consistency under scale.

Key Requirements

Functional

• Restaurant search -- users search for restaurants by name, cuisine, or location, with results defaulting to a 30-mile radius around the user
• Availability and booking -- users view up-to-date availability and book reservations for a specific date, time, and party size (individual or group)
• Reservation editing -- users edit an existing reservation (e.g., time or party size) and receive updated confirmation
• Reservation cancellation -- users cancel a reservation and receive confirmation of the cancellation

Non-Functional

• Scalability -- handle millions of search queries per day and thousands of concurrent booking attempts during peak dining hours (Friday/Saturday 6-8pm)
• Reliability -- guarantee no double-bookings under concurrent load; ensure 99.9% uptime for booking transactions with graceful degradation for search during partial outages
• Latency -- return search results within 300ms at p95; complete booking confirmation within 2 seconds including hold acquisition
• Consistency -- strong consistency for inventory updates during booking; eventual consistency acceptable for search index updates and availability display

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Contention and Double-Booking Prevention

Table inventory is a scarce resource and peak times create hot keys/rows. When multiple users attempt to book the last table at a popular restaurant for Friday 7pm, your system must prevent overselling while maintaining throughput.

Hints to consider:

• Use unique constraints or conditional writes (e.g., INSERT ... ON CONFLICT or SELECT FOR UPDATE) to atomically claim a time slot for a specific table group
• Implement short-lived holds with TTL in Redis so users have a window to complete payment without blocking inventory indefinitely
• Assign idempotency keys to booking requests so retries from network failures do not create duplicate reservations
• Partition table inventory by restaurant to reduce lock contention scope and enable parallel booking across different restaurants

2. Geo and Text Search at Scale

Users need fast, relevant search results filtered by location, cuisine, and name. Search traffic vastly exceeds booking volume, so your read path must scale independently from the write path.

Hints to consider:

• Use Elasticsearch with native geo-distance queries for the 30-mile default radius and full-text analyzers for name and cuisine matching
• Precompute and denormalize availability flags in the search index, refreshing asynchronously from booking events via CDC or message queue
• Cache popular search queries and trending restaurants per neighborhood in Redis with appropriate TTLs
• Paginate results and fetch detailed slot availability only for restaurants on the current page

3. Real-Time Availability Updates

Diners and restaurant consoles must see availability changes as they happen to reduce failed bookings. Stale availability leads to frustrating user experiences where users attempt to book slots that are already taken.

Hints to consider:

• Use WebSockets or Server-Sent Events to push availability changes to clients viewing a specific restaurant's slots
• Implement cache invalidation on booking events so search results reflect updated availability within seconds
• Apply fan-out strategies scoped to individual restaurants to avoid broadcasting irrelevant updates
• Consider a hybrid approach: poll for search results but push for real-time slot updates on the detail page

4. Multi-Step Booking Workflow

Edits, cancellations, and confirmations are multi-step workflows that cross services (availability, notifications, payments/penalties). A reservation edit is not a simple in-place update -- it requires holding the new slot before releasing the old one.

Hints to consider:

• Model reservations with a state machine (HOLD -> CONFIRMED -> MODIFIED -> CANCELLED) with explicit transitions and compensating actions
• For edits, use a safe swap pattern: hold the new slot first, then release the old slot, so failures do not lose both reservations
• Use saga pattern to coordinate steps across availability, payment, and notification services
• Store audit logs of all state transitions for customer support and dispute resolution

5. Data Modeling for Time Slots and Tables

How you model restaurant capacity directly affects query performance and correctness. Interviewers want to see thoughtful schema design that supports efficient availability checks.

Hints to consider:

• Model capacity as table groups (e.g., "2-top", "4-top", "6-top") with counts per time slot rather than individual table records
• Store time slots at fixed intervals (e.g., 30-minute windows) to simplify availability queries and reduce row count
• Use composite indexes on (restaurant_id, date, time_slot, table_group_id) for efficient range scans
• Consider separate tables for restaurant metadata versus time-varying inventory to optimize read patterns

Suggested Approach

Step 1: Clarify Requirements

Confirm the scope with your interviewer. Ask about expected scale: how many restaurants, how many concurrent users during peak hours, and whether the system covers a single city or multiple regions. Clarify the 30-mile default radius and whether users can adjust it. Ask whether payment is in scope or if you should focus on the reservation flow. Determine whether restaurants manage their own availability through an admin interface or if it's pre-configured. Verify whether group reservations have size limits and whether special requests (outdoor seating, high chairs) need to be supported.

Step 2: High-Level Architecture

Sketch a service-oriented architecture with clear separation of concerns. A Search Service backed by Elasticsearch handles geo and text queries, returning restaurant metadata and availability summaries. A Booking Service owns the transactional workflow, interacting with PostgreSQL to check precise slot availability and create reservations. An Availability Service maintains per-slot inventory counts and publishes change events. A Notification Service handles confirmations, reminders, and cancellation emails. Place Redis in front of hot paths for caching search results and managing short-lived holds during checkout. Use a message queue (Kafka) to decouple inventory updates from search reindexing, ensuring eventual consistency without blocking booking transactions.

Step 3: Deep Dive on Booking Flow

Walk through the core booking transaction in detail. When a user selects a restaurant, date, time, and party size, the Booking Service starts a database transaction. It queries the availability table: SELECT available_count FROM slots WHERE restaurant_id = ? AND date = ? AND time_slot = ? AND table_group_id = ? FOR UPDATE. If a suitable table group has capacity, it decrements the count and inserts a reservation row with a CONFIRMED status and generated confirmation code. The service then sends a confirmation event to Kafka for the Notification Service. Discuss how FOR UPDATE row locks prevent concurrent transactions from double-booking, and how the composite index ensures the query completes in milliseconds. For the hold pattern, explain how Redis stores a hold with a 5-minute TTL, converting to a confirmed reservation only after user completes the flow.

Step 4: Address Secondary Concerns

Cover remaining non-functional requirements. For scalability, partition the slots table by date to keep active queries fast and archive historical data. Use read replicas for search-related availability queries that tolerate slight lag. For reliability, implement idempotency tokens on booking requests so retries from client timeouts do not create duplicate reservations. Use circuit breakers around notification service calls to avoid blocking the booking path. For latency, explain how caching popular restaurant searches in Redis with 2-minute TTLs reduces Elasticsearch load, and how precomputing availability summaries avoids aggregation queries. For consistency, describe how booking events publish to Kafka and a consumer updates the Elasticsearch index, accepting eventual consistency in search while guaranteeing strong consistency in the booking path. Finally, touch on observability: track booking success rates, hold conversion rates, search latency percentiles, and contention metrics to tune under load.

Real Interview Quotes

"User should be able to book a restaurant by selecting filter like a day, approximate time, no of people. In return, there are no of slot listed before and after to the given time slots."

"Design a system to make restaurant reservations. Users should be able to search for a restaurant based on name/cuisine/location, make single/group reservations. By default, we need to show all the restaurants within 30 miles of users location."

"Design a restaurant booking service users can reserve, edit and delete booking."