Design a Ticketing Master System
Design a service for selling high-demand event tickets. Focus on concurrency control (preventing double-booking) using database locks or transactional systems.
Why Interviewers Ask This
Uber asks this to evaluate your ability to design systems handling extreme concurrency where data integrity is non-negotiable. They specifically test if you can architect a solution that prevents double-booking during flash sales, balancing strict ACID compliance with high availability and low latency under massive traffic spikes.
How to Answer This Question
1. Clarify requirements immediately: define scale (e.g., millions of concurrent users), consistency needs (zero double-booking), and latency targets. 2. Model the domain: identify core entities like Events, Seats, and Users, focusing on the critical path of seat reservation. 3. Address the concurrency bottleneck: propose a two-phase locking strategy using database transactions or optimistic locking with versioning to prevent race conditions. 4. Design for scalability: suggest sharding strategies by event ID and caching hot data with Redis, ensuring the write path remains efficient. 5. Discuss trade-offs: explain how you handle edge cases like network timeouts or payment failures without releasing seats prematurely, referencing Uber's need for reliable, real-time services.
Key Points to Cover
- Explicitly defining the zero-double-booking constraint as the primary success metric
- Proposing specific database locking mechanisms like SELECT FOR UPDATE or optimistic locking
- Demonstrating knowledge of sharding strategies to handle horizontal scaling per event
- Addressing the timeout and retry logic for failed reservations to prevent deadlocks
- Connecting the technical solution to real-world reliability standards expected at Uber
Sample Answer
To design a robust ticketing system for high-demand events, I would first establish strict consistency requirements since double-booking is unacceptable. The core challenge is the 'thundering herd' problem where thousand…
Common Mistakes to Avoid
- Ignoring the concurrency aspect entirely and focusing only on basic CRUD operations
- Suggesting eventual consistency which could lead to overselling tickets during peak loads
- Failing to mention how to handle network failures or timeouts during the reservation process
- Overlooking the need to shard data by event ID rather than trying to load-balance a single massive table
Sound confident on this question in 5 minutes
Answer once and get a 30-second AI critique of your structure, content, and delivery. First attempt is free — no signup needed.