Practice/Meta/Design a price notification system

Design a price notification system

System DesignMust

Problem Statement

Design a real-time restaurant reservation platform similar to OpenTable or Resy that allows diners to search for available tables, make reservations, and receive confirmations. The system must handle millions of concurrent searches across thousands of restaurants while preventing double-bookings and managing inventory turnover throughout the day.

The core challenge is managing highly contended resources (individual tables at specific times) under heavy concurrent load, especially during peak booking windows like Friday evenings. The system needs to ensure exactly-once reservation semantics, provide low-latency availability searches, and gracefully handle last-minute cancellations that immediately return inventory to the pool. Expect to discuss reservation lifecycle management, inventory visibility strategies, and how to balance consistency requirements with user experience.

Key Requirements

Functional

• Search and discovery -- users can search restaurants by location, cuisine, time, and party size with real-time availability display
• Reservation booking -- users can reserve specific time slots with guaranteed inventory atomicity and immediate confirmation
• Reservation management -- users can view, modify, or cancel existing reservations with appropriate notice periods
• Restaurant operations -- restaurant partners can configure table layouts, hours, booking rules, and manually adjust availability
• Waitlist and notifications -- users can join waitlists for fully booked slots and receive alerts when tables become available

Non-Functional

• Scalability -- support 10K+ restaurants, 100K concurrent users, 1M+ reservations per day with spiky traffic patterns
• Reliability -- prevent double-bookings under all failure scenarios; support 99.9% uptime with graceful degradation
• Latency -- availability searches under 300ms p99, booking confirmation under 500ms, with optimistic UI updates
• Consistency -- strong consistency for reservation writes; eventual consistency acceptable for search results and availability displays

What Interviewers Focus On

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

1. Inventory Management and Concurrency Control

The hardest problem is preventing double-bookings when hundreds of users simultaneously attempt to reserve the same 7pm slot. Naive approaches like read-then-write create race conditions, while overly pessimistic locking degrades user experience.

Hints to consider:

• Compare optimistic locking (check version on write) versus pessimistic locking (hold locks during checkout flow)
• Consider how to model table inventory: individual tables vs. aggregated capacity buckets vs. time-slot tokens
• Discuss reservation expiry and hold mechanisms during the checkout process
• Explore distributed transaction patterns like Saga or two-phase commit for multi-restaurant bookings

2. Search and Availability Display Strategy

Showing accurate real-time availability across thousands of restaurants is expensive, but showing stale data frustrates users who encounter "unavailable" errors at checkout. The tradeoff between freshness and query cost is critical.

Hints to consider:

• Evaluate caching strategies with time-to-live policies versus streaming availability updates to search results
• Discuss the use of pre-computed availability snapshots at 15-minute granularity versus on-demand calculation
• Consider read replicas and CQRS patterns to separate availability reads from reservation writes
• Explore how to handle "phantom availability" when cached results become stale between search and booking

3. Peak Load Management and Graceful Degradation

Popular restaurants see reservation stampedes the moment a new booking window opens (e.g., 30 days in advance). The system must prevent cascading failures while maintaining fairness.

Hints to consider:

• Design a queueing mechanism with position tracking when demand exceeds capacity
• Discuss rate limiting strategies per user, per restaurant, and globally to prevent abuse
• Consider circuit breakers and backpressure patterns to protect downstream services
• Evaluate lottery or randomized access windows versus pure first-come-first-served

4. Time Zone Handling and Business Rules

Restaurants operate in local time zones, but users search and book from anywhere. Mismatched time handling causes incorrect availability and user frustration.

Hints to consider:

• Store all times in UTC internally but display and accept input in restaurant local time
• Handle daylight saving transitions that create ambiguous or non-existent hours
• Manage business rules like minimum party size, maximum advance booking, and last-minute cutoff windows
• Consider how to enforce cancellation policies with appropriate notice periods