Katkat

Design a Ticketmaster-like ticketing system

AffirmSoftware Engineer · Onsite

Last updated

This question tests your ability to design a high-concurrency booking system, focusing on preventing double-bookings, managing seat holds, and ensuring system availability during high-traffic events.

System Design: Event Ticketing Platform

Design a scalable online ticketing system similar to Ticketmaster. The system must handle high-traffic spikes during popular concert ticket releases (the "thundering herd" problem).

Functional Requirements

  1. Users can view available seats for a specific event.
  2. Users can select and reserve specific seats.
  3. The system must process payments and confirm the booking.
  4. Reserved seats should be held for a limited time (e.g., 10 minutes) before being released if payment is not completed.

Non-Functional Requirements

  1. Consistency: Prevent overbooking (no two users can purchase the same seat).
  2. Availability: The system must remain responsive during high-load traffic.
  3. Latency: Seat selection and checkout should be fast, even under heavy load.

Constraints & Assumptions

  • Assume 1 million concurrent users at the start of a major ticket release.
  • There are 50,000 seats per event.
  • Reads (viewing seats) vastly outnumber writes (purchasing).

Deliverables

  • Define the core APIs (e.g., getSeats, reserveSeat, purchaseSeat).
  • Propose a data model (SQL vs. NoSQL) to handle inventory and seat status.
  • Describe how you manage the temporary lock (seat hold) and ensure data consistency.
  • Propose a strategy for handling the surge in traffic during a release.

Hints

Hint 1

Consider using a distributed locking mechanism or a database transaction with row-level locking to handle seat concurrency.

Hint 2

Think about using a message queue or a caching layer (like Redis) to offload database pressure during the peak of a ticket drop.

Hint 3

Decide whether to use a synchronous or asynchronous architecture for payment processing to ensure the user receives immediate feedback.

Follow-up questions

  • How would you handle the 'bot' problem where automated scripts try to buy all tickets at once?
  • If the database becomes a bottleneck during the 'reserveSeat' operation, what sharding strategies would you implement?
  • How would you ensure the seat hold timer remains accurate if a user's browser crashes or they lose internet connection?