High-Level Design: Scaling a Concert Ticket Booking System under Flash Load

Scenario context

Designing a high-scale ticket booking system requires balancing high read traffic (seat map lookups) with extreme write concurrency (seat lock attempts) during popular concert drops. We achieve this using Redis-based temporary ticket locks and distributed queues.

Imagine the ticketing drops for a global pop star. Within seconds of going live, a stadium with 50,000 seats receives over 1 million concurrent conne…

This walkthrough focuses on System Overview & Scale-Based Design Challenge.

Before making a design choice, clarify:

• Imagine the ticketing drops for a global pop star.
• Within seconds of going live, a stadium with 50,000 seats receives over 1 million concurrent connection requests.
• If the system is not designed to handle this traffic, database locking bottlenecks occur immediately.

Concepts in play: system-design-hld-architectures, caching, distributed-locking, event-driven-architecture

Stage 1 — Core Requirements and Capacity Estimation

• To establish a clear design scope, we define our requirements and estimate the system capacity.
• Functional Requirements Search & View Event: Users can search for events and view available seats in real-time.
• Reserve Seats: Users can temporarily hold/lock seats for 10 minutes while they enter payment details.
• Confirm Booking: Users complete payment, converting the hold into a confirmed booking.

Observable outcome: Confirm Booking: Users complete payment, converting the hold into a confirmed booking.

Stage 2 — Core Mechanics: API, Schema, and Storage Architecture

• Our system uses separate read and write paths to scale.

Observable outcome: Our system uses separate read and write paths to scale.

Stage 3 — Practical Interview Execution: 45-Minute Delivery Strategy

• When presenting this design in an interview, manage your time using this schedule: 1.
• Minutes 0-5 (Clarify Requirements): Establish scale expectations (Active users, QPS) and write functional requirements on the whiteboard.
• Minutes 5-15 (High-Level Architecture): Sketch the CDN, Gateway, Read/Write split services, and database layers.
• Minutes 15-30 (Deep Dive): Explain how you prevent double-booking using Redis distributed locks.

Observable outcome: Minutes 15-30 (Deep Dive): Explain how you prevent double-booking using Redis distributed locks.

Stage 4 — Apache Kafka: Messaging Configuration

• In high-concurrency booking systems, Apache Kafka is configured with partition keys set to event id .
• This ensures that all transactions for a specific concert drop are processed in order by the same worker instance, preventing write conflicts.
• We configure the topic with replication factor 3 and acks=all to guarantee that message commits are persisted across multiple broker instances, protecting the system against broker failures during drops.

Observable outcome: We configure the topic with replication factor 3 and acks=all to guarantee that message commits are persisted across multiple broker instances, protecting the system against broker failures during drops.

End-to-end outcome

After working through the stages, you should be able to explain:

• Redis Locks: Use Redis distributed locks for fast, memory-based seat validation.
• Decoupled Paths: Separate the high-traffic seat selection path from the transactional payment system.

Alternatives considered

The source focuses on one primary design. A second architecture is not compared, so no alternative is invented here.

Failure and degraded modes

Lessons Learned: Production Scaling Pitfalls

• Detection: Avoid these standard mistakes when deploying booking platforms to production: Setting Long Lock Durations: Keeping seat locks active for too long (e.g., 30 minutes) allows users to tie up inventory w…
• User or operator impact: Avoid these standard mistakes when deploying booking platforms to production: Setting Long Lock Durations: Keeping seat locks active for too long (e.g., 30 minutes) allows users to tie up inventory w…