Practice/Meta/Design a Ticket Booking System

Design a Ticket Booking System

System DesignMust

Problem Statement

Design a restaurant reservation platform similar to OpenTable that allows diners to discover restaurants, check real-time table availability, make reservations, and manage bookings. The system must handle peak dining hours when thousands of users compete for limited tables at popular restaurants, ensure fair access to inventory, and prevent double-bookings while maintaining a smooth user experience.

The platform serves both diners searching for available tables and restaurant partners managing their floor plans, time slots, and special events. Your design should handle scenarios like Valentine's Day when a single Michelin-starred restaurant might receive hundreds of requests within seconds of opening reservations, coordinate with payment systems for deposits or no-show fees, and send timely confirmations and reminders. This problem tests your ability to manage contended inventory with time-sensitive holds, orchestrate multi-step booking workflows, and maintain data consistency across distributed components under variable load.

Key Requirements

Functional

• Restaurant discovery and search -- Users can browse restaurants by cuisine, location, price range, and availability for specific date-time slots
• Real-time availability checking -- Users can view open tables for their desired party size and time, with instant updates as inventory changes
• Reservation creation with temporary holds -- Users can select a time slot that gets temporarily reserved for 10-15 minutes while they complete booking
• Booking confirmation and management -- Users can finalize reservations with optional payment deposits, receive confirmations, and modify or cancel bookings
• Restaurant partner tools -- Restaurant staff can configure table layouts, operating hours, special closures, and view/manage incoming reservations

Non-Functional

• Scalability -- Support 10,000+ concurrent users during peak hours, with 500+ reservations per second across the platform
• Reliability -- Guarantee no double-bookings even during failures; maintain 99.9% uptime with graceful degradation
• Latency -- Return search results within 300ms, availability checks within 200ms, and booking confirmations within 2 seconds
• Consistency -- Strong consistency for table inventory to prevent overbooking; eventual consistency acceptable for search indexes and analytics

What Interviewers Focus On

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

1. Inventory Contention and Double-Booking Prevention

Managing table availability is the core challenge. Multiple users simultaneously requesting the same time slot at a popular restaurant creates severe contention. Your design must atomically update inventory, prevent race conditions, and maintain correctness under concurrent access without sacrificing performance.

Hints to consider:

• Consider optimistic vs pessimistic locking strategies for table assignments and when each makes sense
• Think about how to structure table availability data to minimize lock scope and conflict windows
• Explore using versioning or compare-and-swap operations to detect and retry conflicts
• Discuss whether to handle general availability counters differently from specific table assignments

2. Temporary Hold Mechanism and Expiration

Users need time to complete booking without others stealing their selection, but holds cannot last forever or inventory gets artificially constrained. Your system must reliably expire abandoned holds, return inventory to the available pool, and handle edge cases like users completing checkout just as their hold expires.

Hints to consider:

• Design a distributed timer or TTL mechanism that works across multiple servers and survives failures
• Consider how to make hold expiration idempotent so retries don't corrupt state
• Think about whether holds should block other users entirely or allow waitlisting and notifications
• Discuss strategies for handling payment processing delays that exceed the hold window

3. Multi-Step Booking Workflow Orchestration

A complete reservation involves checking availability, creating a hold, processing payment (if required), confirming the booking, sending notifications, and updating various subsystems. This workflow must be atomic and recoverable, with proper handling of partial failures, timeouts, and duplicate requests.

Hints to consider:

• Model the booking process as a state machine with clear transitions and compensating actions
• Use idempotency keys to safely retry failed operations without creating duplicate reservations
• Consider the transactional outbox pattern to reliably trigger downstream events like emails
• Discuss how to handle payment gateway webhooks that arrive out of order or duplicate

4. Fair Access During High Demand

When reservations open for exclusive events or highly sought restaurants, uncontrolled traffic can overwhelm the system and create an unfair free-for-all. Your design should include mechanisms to protect backend services while giving all users a reasonable chance to book.

Hints to consider:

• Implement a virtual waiting room or queue system to control admission rate during traffic spikes
• Use rate limiting per user to prevent automated bots from monopolizing inventory
• Consider randomized selection from the queue rather than pure first-come-first-served
• Discuss how to provide queue position updates and estimated wait times to users