Practice/Google/Design a Waitlist System for Restaurant Management

Design a Waitlist System for Restaurant Management

System DesignMust

Problem Statement

Design a digital waitlist system that lets restaurants manage their queues remotely. Guests join a waitlist from their phone, receive an estimated wait time, and get notified when their table is ready. The system replaces the old clipboard-and-buzzer model with a scalable platform serving thousands of restaurants simultaneously.

The central challenge is maintaining accurate, real-time queue state across concurrent operations — guests joining, leaving, being seated, or being skipped — while providing reliable wait time estimates that adapt to each restaurant's seating pace. You also need to handle edge cases like no-shows, parties that change size, and peak-hour surges.

The system should support both walk-in guests (added by the host) and remote guests who join from a web link or app, with real-time position updates and notification delivery.

Key Requirements

Functional

• Queue management -- Guests join the waitlist with their party size and contact info; hosts can seat, skip, or remove guests from the queue.
• Estimated wait times -- Provide dynamic wait time estimates based on current queue depth, historical seating rates, and party size.
• Notifications -- Send real-time notifications (SMS or push) when a guest's table is ready or their position changes significantly.
• Multi-restaurant support -- Each restaurant operates an independent waitlist with its own configuration (table sizes, hours, capacity).

Non-Functional

• Scalability -- Support 50,000+ restaurants with concurrent active waitlists during peak dining hours.
• Latency -- Queue operations (join, seat, skip) complete in under 200ms.
• Reliability -- Never lose a guest's position in the queue due to system failures.
• Real-time updates -- Position and wait time changes propagate to guests within 2 seconds.

What Interviewers Focus On

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

1. Queue Data Structure and Ordering

How you model the waitlist determines the efficiency of insertions, removals, and position lookups. Hints to consider:

• Consider using a Redis sorted set with join timestamp as the score for O(log N) operations
• How do you handle priority guests or reservations that convert to waitlist entries?
• What happens when a host seats someone out of order — how do you update positions for everyone behind them?
• Think about partitioning queues by restaurant ID to avoid cross-restaurant contention

2. Wait Time Estimation

Accurate estimates keep guests happy; wildly wrong ones drive them away. Hints to consider:

• Track the rolling average time between seatings over the last hour as a baseline
• How does party size affect the estimate — a party of 6 waits differently than a party of 2?
• Consider using exponential moving averages to weight recent seating events more heavily
• What signal do you use to detect that a restaurant is clearing its queue faster or slower than usual?

3. Notification Delivery

Guests depend on timely notifications, and missed messages mean empty tables. Hints to consider:

• Use Kafka to decouple queue state changes from notification dispatch
• How do you handle SMS delivery failures — retry with backoff or fall back to push notifications?
• Consider batching position update notifications to avoid spamming guests with every small change
• What is your strategy for guests who never respond to a notification — auto-skip after timeout?