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 thousands of users compete for the last few seats simultaneously. My approach starts with a relational database schema where each seat is a row in an Event_Slots table with a unique constraint. For concurrency control, I would implement a distributed lock mechanism using Redis Redlock before entering a database transaction. This ensures only one request processes a specific seat at a time. Inside the transaction, we use SELECT FOR UPDATE to lock the row, verify availability, decrement the count, and commit atomically. If the lock fails or the transaction times out, we retry with exponential backoff. To handle scale, I would shard the database horizontally by Event ID, allowing parallel processing across different events. Additionally, a read-heavy cache layer serves event details, while the write path goes directly to the database. We must also implement a short-lived hold period (e.g., 10 minutes) for uncompleted purchases to free up inventory automatically. This architecture mirrors Uber's requirement for real-time, fault-tolerant systems where financial integrity and user trust are paramount.
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
Practice This Question with AI
Answer this question orally or via text and get instant AI-powered feedback on your response quality, structure, and delivery.