Katkat
Back

Design a Multi-Region Event Ticketing System

AddeparSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

This question tests the ability to design a highly concurrent distributed system that balances strong consistency for inventory management with high availability for a global, read-heavy user base.

Design a Global Event Ticketing System

Design a scalable ticketing platform (similar to Ticketmaster) that supports global events. The system must handle massive spikes in traffic during "hot" ticket drops while ensuring that no ticket is double-sold.

Functional Requirements

  1. Event Discovery: Users can browse and search for events by location, category, and date.
  2. Inventory Management: Events have multiple sections with varying prices and seating capacities.
  3. Reservation Lifecycle: When a user selects seats, those seats must be held exclusively for 10 minutes. If payment is not completed, the hold expires and the seats return to the available pool.
  4. Atomic Checkout: Finalize ticket purchase and generate a confirmation.

Non-Functional Requirements

  1. High Throughput: Must handle massive spikes in read traffic (searches/event details) and write traffic (checkouts) during peak drops.
  2. Consistency: The system must provide strong consistency for seat inventory; overselling is not permitted.
  3. Availability: The system must remain available even if a specific regional data center experiences a partial outage.

Your Design Should Cover

  • API Design: Define the primary endpoints for searching, holding, and purchasing tickets.
  • Data Model: Describe the database schema/structure for events, sections, and inventory.
  • Concurrency Control: How do you prevent two users from claiming the same seat at the same time at global scale?
  • System Architecture: Explain the trade-offs between consistency and latency when handling distributed state across regions.

Hints

Hint 1

Consider using a distributed lock manager or a database-level atomic increment/decrement to manage seat availability.

Hint 2

For the 10-minute hold, evaluate the use of a message queue or a scheduled job mechanism compared to a time-to-live (TTL) approach in a cache.

Hint 3

Separate the read path (using CDNs or read replicas) from the write path to handle the disproportionate volume of search requests vs. booking requests.

Follow-up questions

  • How would you handle a scenario where a payment provider's API latency increases significantly during a high-traffic event?
  • If you have to perform a database migration for the seat inventory, how would you minimize downtime while maintaining data integrity?
  • How would you prevent a botnet from exhausting the seat-hold inventory of a popular event?