Katkat
Back

Design a High-Demand Event Ticket Marketplace

MercorMachine Learning Engineer · Onsite
MediumMachine Learning EngineerOnsiteSystem Design

Last updated

Design an event ticketing platform capable of handling flash-sale spikes without overselling, featuring transactional seat holds, idempotent payment processing, and virtual queueing.

Scenario

Design the core architecture for a high-demand event ticketing platform (similar to Ticketmaster or DICE). The platform must handle major stadium on-sales where millions of fans compete for a limited number of seats simultaneously, ensuring zero overselling, fair access, and robust checkout lifecycles.

Requirements

Functional Requirements

  • Seat Discovery & Map: Users can view venue seat availability and pricing in near real-time.
  • Temporary Hold (Carting): A user can select available seats and place an exclusive, temporary hold (e.g., 10 minutes) while completing payment.
  • Checkout & Payment: Process payments idempotently; confirm the booking upon successful payment or release seats upon expiration or cancellation.
  • Queue / Waiting Room: Regulate traffic surges during on-sales to protect downstream systems and ensure fair distribution.

Non-Functional Requirements

  • Strict Consistency (Zero Overselling): A seat must never be sold to more than one user under any circumstance.
  • High Availability & Low Latency: Seat map browsing p99 latency < 200 ms; seat holding latency < 500 ms.
  • Scalability: Support massive traffic bursts at the exact drop second.
  • Fault Tolerance: Handle network drops, payment gateway delays, and abandoned checkouts gracefully.

Scale & Traffic Assumptions

  • Venue Size: Up to 80,000 seats per event.
  • Peak Traffic: 2,000,000 concurrent users active at the start of an on-sale.
  • Throughput:
    • Seat browsing: ~100,000 read requests per second (RPS).
    • Hold attempts: ~30,000 write RPS focused on a narrow subset of seats.

What to Cover

  1. High-Level Architecture & Traffic Flow: From user ingress, waiting room, edge caching, through core services to databases.
  2. Seat State Machine & Inventory Storage: Define the state transitions (AVAILABLE, HELD, SOLD) and describe the database design / locking mechanisms (e.g., optimistic locking, distributed transactions, or Redis Lua scripts with write-behind) that prevent race conditions.
  3. Expiring Holds & Reconciliation: How to manage hold leases safely with fencing tokens, handling scenarios where payment succeeds right as the hold expires.
  4. Waiting Room & Bot Mitigation: Token-based admission control, rate limiting, and behavioral fraud checks.
  5. Payment Idempotency & Failure Scenarios: Handling asynchronous webhooks, partial failures, and recovery.

Hints

Hint 1

Decouple high-volume seat map reads from transactional reservation writes using a CQRS pattern with an eventually consistent read cache and a strongly consistent write store.

Hint 2

Use a virtual waiting room with cryptographically signed, expiring admission passes to throttle ingress traffic down to what the transactional inventory engine can safely process.

Hint 3

Rely on idempotent payment tokens and explicit fencing versions to resolve race conditions between expiring holds and slow payment webhook confirmations.

Follow-up questions

  • What exact mechanism would you use to resolve a situation where payment succeeds 2 seconds after the hold TTL expires and another user has already placed a hold on the same seat?
  • How would you integrate real-time ML risk scoring into the waiting-room-to-cart funnel without degrading checkout latency?
  • How does your database sharding strategy scale if thousands of users attempt to reserve contiguous seats in the same section simultaneously?