Design a Restaurant Reservation System

Problem Design a restaurant reservation system (OpenTable-style): search restaurants and time slots, book/cancel reservations, never double-book a table.

Functional requirements

• Search by location/cuisine/date/party size → restaurants with available slots; book a slot (party size, contact), modify/cancel; restaurant-side management: table inventory, seating durations, blackout dates; reminders/waitlist as extensions.

Non-functional requirements

• Consistency on booking (a table-slot is booked once); search read-heavy and cacheable; peak spikes (weekend evenings, holidays like Valentine's Day).

Key components

• Restaurant/catalog service (profiles, hours, table configs), availability service (inventory: table × time-slot grid derived from hours and seating duration), reservation service (transactional booking, state machine: pending → confirmed → seated/no-show/cancelled), notification service, search service with cached availability summaries.

Deep dives / trade-offs

• Inventory model: discrete time slots (15/30-min granularity rows per table-date) vs interval-based booking with overlap checks — slots are simpler and index-friendly; discuss turn-time (a 2-hour seating consumes multiple slots).
• Double-booking: unique constraint on (table_id, slot) + transaction, or optimistic locking; table-assignment strategy (best-fit party size) done at booking vs at seating.
• Cached search availability going stale under contention — accept and recheck authoritatively at booking; waitlist and overbooking policy (no-show rates) as senior-level discussion.