Design a ticketing purchase system

Quick Overview

This question evaluates understanding of large-scale system design and distributed systems concepts, including concurrency control, consistency models, real-time fanout, payment idempotency, and failure handling for high-concurrency ticketing with interactive seat maps.

System Design: High-Concurrency Ticket Purchasing With Seat Maps

You are asked to design an end-to-end ticketing system for large on-sale events (e.g., concerts, sports) with interactive seat maps and extreme traffic spikes. The system must handle concurrent seat selection, payment, and real-time updates while preventing oversells.

Functional Requirements

Interactive seat selection on a seat map (single and multi-seat selection, contiguous seats).
Seat holds with TTL (e.g., 2–5 minutes) and renewal, visible across devices.
Purchasing flow with payment authorization/capture, idempotency, and retries.
Refunds and chargebacks handling with appropriate state transitions.
Wait queues during spikes; fair admission and anti-bot protections.
Real-time availability updates to clients.
Audit logging for compliance and investigations.

Non-Functional Requirements

Prevent oversells under massive concurrent demand.
High write throughput and burst tolerance (tens of thousands of holds/s).
Low-latency seat availability reads (<150 ms p95) and updates.
Horizontally scalable (sharding, caching) and resilient to failures.
Clear consistency model and locking approach.

Deliverables

Discuss and justify:

Data model and key constraints.
Public APIs and core flows (hold, purchase, refund, real-time updates).
Concurrency control and locking (pessimistic vs. optimistic).
Consistency model and how you prevent oversells.
Scaling strategy (sharding, caching, queueing, real-time fanout).
Failure handling, idempotency, retries, and auditability.

Quick Overview