Each test is 5 questions with varying difficulty.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.
Designing a ticket booking system is a classic high-concurrency system design interview question that tests a candidate's ability to handle extreme traffic spikes, ensure data consistency, and manage distributed state. In 2026, these systems must handle millions of requests per second during peak events, requiring advanced knowledge of distributed locking, database isolation levels, and asynchronous processing. For junior engineers, the focus is on basic database schema design and simple locking mechanisms. For senior candidates, interviewers expect deep discussions on trade-offs between ACID compliance and performance, handling 'thundering herd' problems, and implementing robust inventory management that prevents overselling without sacrificing availability. Mastery of this topic demonstrates an understanding of how to bridge the gap between user-facing responsiveness and backend data integrity.
The ticket booking system is a high-signal interview question because it exposes a candidate's practical grasp of the CAP theorem and distributed state management. Unlike CRUD applications, booking systems face the 'hot key' problem: thousands of users competing for the same limited set of seats simultaneously. A weak candidate will suggest simple row-level locking in a relational database, which leads to immediate performance degradation under load. A strong candidate will propose a multi-layered approach involving in-memory inventory management (e.g., Redis), asynchronous event processing for payment confirmation, and optimistic concurrency control to maintain high throughput. In 2026, with the rise of global ticketing platforms, the ability to design systems that handle 'flash sales' without crashing is a critical skill. This topic evaluates whether a candidate can design for failure, manage eventual consistency, and implement effective rate limiting to protect the system core during massive traffic surges.
The architecture follows a layered approach: a Load Balancer directs traffic to stateless API services, which interact with a fast, in-memory cache (Redis) for seat availability checks. The primary database (PostgreSQL) acts as the source of truth, while an asynchronous message queue (Kafka) handles the downstream processing of successful bookings, such as email notifications and loyalty point updates.
[Client Request]
↓
[Load Balancer]
↓
[API Gateway]
↓
[Booking Service]
↓ ↓
[Redis Cache] [PostgreSQL]
↓ ↓
[Message Queue]
↓
[Notification Service]Set a Time-To-Live (TTL) on a locked seat in Redis; if payment isn't completed, the lock expires and the seat is released.
Trade-offs: Ensures availability but requires background cleanup tasks.
Write booking data and the corresponding event to the same database in one transaction, then have a relay service push the event to Kafka.
Trade-offs: Guarantees at-least-once delivery but increases database load.
Partition seat inventory by event_id across different Redis clusters to avoid hot keys.
Trade-offs: Improves performance but makes cross-event reporting harder.
| Reliability | Use circuit breakers for payment gateways and implement dead-letter queues for failed events. |
| Scalability | Horizontal scaling of stateless services and sharding the inventory database. |
| Performance | Target sub-100ms latency for seat selection using Redis; use CDNs for static assets. |
| Cost | Optimize database storage by archiving old bookings; use spot instances for non-critical background jobs. |
| Security | Implement rate limiting, OAuth2 for API access, and encrypt sensitive user data at rest. |
| Monitoring | Track P99 latency, booking success rate, and Redis lock contention metrics. |
A ticket booking system deals with unique, non-fungible inventory (specific seats) and extreme bursts of traffic for limited time windows. E-commerce systems often handle fungible items (e.g., 100 units of a shirt) where inventory is pooled. The primary challenge in ticketing is the contention for specific, high-value seats, requiring much stricter locking and concurrency control than typical retail inventory.
Database transactions are expensive and hold locks, which limits throughput. In a high-concurrency booking system, holding a database lock for the duration of a user's payment process would cause massive contention and system-wide slowness. We use in-memory caches and optimistic concurrency to keep the database transaction duration as short as possible.
Redis is excellent for high-speed availability checks and locking, but it is not a durable source of truth. It must be paired with a persistent relational database. Redis is the 'fast path' for performance, while the database is the 'safe path' for persistence and auditability.
Overselling is prevented by using atomic operations (e.g., Redis DECR or SQL UPDATE with versioning) and ensuring that the final booking confirmation is contingent on a successful inventory decrement. If two users attempt to book the same seat, only one will succeed in the atomic operation, and the second will receive a failure notification.
Pessimistic locking prevents others from accessing data while a transaction is in progress, which is safe but slow. Optimistic locking assumes conflicts are rare, allowing multiple users to read/write, but checking for conflicts at the commit stage. Optimistic is generally preferred for high-concurrency systems to maintain high throughput.
The thundering herd occurs when many processes wait for a resource, and when it becomes available, they all wake up and attempt to acquire it simultaneously. This can overwhelm the system. In booking systems, this happens when a popular event goes live, and thousands of users hit the API at the exact same second.
Abandoned bookings are handled using a TTL (Time-To-Live) mechanism. When a seat is locked, a timer is set. If the payment service does not confirm the booking before the timer expires, the lock is released, and the seat becomes available again. This is typically managed by a background worker or a Redis key expiry event.
Network calls are unreliable. If a payment request times out, the client doesn't know if the payment went through. If they retry without an idempotency key, they might be charged twice. Idempotency keys allow the server to recognize retried requests and return the original result instead of processing the payment again.
A virtual queue acts as a buffer to manage traffic spikes. Instead of letting all users hit the booking service simultaneously, users are placed in a queue and admitted at a rate the system can handle. This protects the backend from being overwhelmed and ensures a stable, albeit slower, experience for users.
Sharding by event_id distributes the load across different database instances. If all events were in one database, a single popular concert could crash the entire system. By sharding, traffic for Concert A goes to Database Node 1, while Concert B goes to Database Node 2, isolating the impact of high-demand events.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.