Large-scale ticketing system design

Design a scalable ticketing platform for peak events that supports real-time bookings, high throughput, low latency, and transactional consistency.

Design a scalable ticketing platform for peak events that supports real-time bookings, high throughput, low latency, and transactional consistency. Use this guide to structure the discussion, test the design under pressure, and practise explaining trade-offs clearly.

Problem and Scope

Design a large-scale ticketing system capable of handling millions of users during peak events. Support event discovery, seat selection, temporary holds, purchase, payment, promo codes, mobile ticket validation, and administrative reporting while preventing overselling.

Start by confirming the core user journey, exclusions, success criteria, and the constraints that materially affect the architecture.

Requirements to Clarify

A strong answer should establish scope before choosing components.

Functional requirements:

Event discovery and search (low-latency reads).
Real-time seat map and selection (for assigned seating).
Temporary holds (seat reservation windows) and final purchase.
Secure payments and payment status tracking.
Promo codes, discounts, and limits per user.
Mobile QR code generation for entry.
Admin dashboards and analytics.
High availability during peaks (Black Friday scale).
Low read latency; high write throughput for purchases.
Strong correctness for inventory (prevent oversell).
Horizontal scalability and multi-region support.
Robust security, fraud detection, and idempotent operations.

Non-functional requirements:

Prevent overselling and preserve an auditable inventory state through retries and partial failures
Keep browsing highly available and low latency while isolating it from the strongly consistent checkout path
Remain operable during extreme hot-event traffic with fair admission and bounded load
Make payment, hold expiry, refund, and ticket issuance workflows idempotent and recoverable
Protect accounts and payments, detect fraud and bots, and support reliable entry validation

Scale and Capacity

Use the workload to justify storage, partitioning, caching, and reliability decisions. Clarify or challenge these assumptions rather than treating them as unquestionable facts:

Peak concurrent users browsing: 1,000,000.
Peak checkout attempts per second: 5,000–20,000 TPS (depending on event).
Average event size: 10k–100k seats.
Orders per day during event: 10M+.
Read-heavy workloads: search and seat map reads ~90% of traffic.
Write-heavy hotspots: inventory and order writes concentrated on popular events.

Architecture Discussion

Walk through the important read and write paths, identify ownership boundaries, and explain how the design behaves when dependencies fail. Cover these areas explicitly:

Event discovery, search, catalog, and cache-heavy browse traffic
Seat inventory model and the hold-confirm-expire state machine
Concurrency control, idempotency, and prevention of overselling
Checkout, payment, refund, and ticket-issuance saga recovery
Waiting room, fair admission, bot controls, and hot-event load shedding
Multi-region ownership, disaster recovery, QR validation, and fraud auditing

Follow-up Questions

Expect the interviewer to test the consequences of your choices. Practise answering these questions with a concrete decision, its benefit, and its cost:

Are tickets reserved by seat (assigned seating) or by general admission?
- Focus: Assess the candidate's answer to "Are tickets reserved by seat (assigned seating) or by general admission" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Is the system global (multi-region) with regional ticket pools, or single-region?
- Focus: Assess the candidate's answer to "Is the system global (multi-region) with regional ticket pools, or single-region" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Are refunds and hold/preview flows required?
- Focus: Assess the candidate's answer to "Are refunds and hold/preview flows required" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Expected SLA for checkout latency (e.g., <2s for reads, <5s for payments)?
- Focus: Assess the candidate's answer to "Expected SLA for checkout latency (e.g., <2s for reads, <5s for payments)" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Are there third-party constraints (payment gateways, KYC, anti-fraud)?
- Focus: Assess the candidate's answer to "Are there third-party constraints (payment gateways, KYC, anti-fraud)" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
How strict must consistency be for inventory? Can we allow eventual consistency for reads but require strong consistency for final purchases?
- Focus: Assess the candidate's answer to "How strict must consistency be for inventory? Can we allow eventual consistency for reads but require strong consistency for final purchases" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Multi-region active-active availability and data replication strategies.
- Focus: Assess the candidate's answer to "Multi-region active-active availability and data replication strategies." for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Reserving bundles (multiple seats) with atomic guarantees.
- Focus: Assess the candidate's answer to "Reserving bundles (multiple seats) with atomic guarantees." for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Dynamic pricing and inventory reservations for presales.
- Focus: Assess the candidate's answer to "Dynamic pricing and inventory reservations for presales." for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Subscription or fan-club priority queues.
- Focus: Assess the candidate's answer to "Subscription or fan-club priority queues." for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Offline/edge validation and intermittent connectivity handling for mobile validation gates.
- Focus: Assess the candidate's answer to "Offline/edge validation and intermittent connectivity handling for mobile validation gates." for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Analytics: real-time dashboards and ML for fraud/demand prediction.
- Focus: Assess the candidate's answer to "Analytics: real-time dashboards and ML for fraud/demand prediction." for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Cost optimization: cold storage for audit logs and tiered read replicas for reporting.
- Focus: Assess the candidate's answer to "Cost optimization: cold storage for audit logs and tiered read replicas for reporting." for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.

Evaluation Rubric

MockMe evaluates the answer across the following dimensions. A complete answer should connect claims to requirements and explain consequential trade-offs.

Requirements and scope (15%): Clarifies and prioritizes the required behavior for Event discovery and search (low-latency reads); Real-time seat map and selection (for assigned seating); Temporary holds (seat reservation windows) and final purchase. Establishes the constraints that materially affect Large-scale ticketing system design, including Prevent overselling and preserve an auditable inventory state through retries and partial failures; Keep browsing highly available and low latency while isolating it from the strongly consistent checkout path. Strong evidence includes Separates the critical path from secondary features and resolves ambiguous requirements before choosing components.
Architecture and interfaces (20%): Presents coherent ownership boundaries and end-to-end flows covering Event discovery, search, catalog, and cache-heavy browse traffic; Seat inventory model and the hold-confirm-expire state machine; Concurrency control, idempotency, and prevention of overselling; Checkout, payment, refund, and ticket-issuance saga recovery. Strong evidence includes Defines interfaces and traces important success, retry, and failure paths across the proposed components.
Data and scaling (25%): Uses workload assumptions such as Peak concurrent users browsing: 1,000,000; Peak checkout attempts per second: 5,000–20,000 TPS (depending on event) to justify capacity and partitioning decisions. Explains the data, state, or model strategy for Event discovery, search, catalog, and cache-heavy browse traffic; Seat inventory model and the hold-confirm-expire state machine. Strong evidence includes Quantifies a dominant workload, identifies the first bottleneck, and explains how the design evolves as that workload grows.
Reliability, correctness, and safety (20%): Explains concrete failure behavior, recovery, and operational safeguards for Concurrency control, idempotency, and prevention of overselling; Checkout, payment, refund, and ticket-issuance saga recovery; Multi-region ownership, disaster recovery, QR validation, and fraud auditing. Strong evidence includes States the required correctness or consistency boundary and covers retries, partial failure, observability, and safe degradation.
Communication and trade-offs (20%): Drives a structured discussion and compares consequential alternatives for Checkout, payment, refund, and ticket-issuance saga recovery; Waiting room, fair admission, bot controls, and hot-event load shedding; Multi-region ownership, disaster recovery, QR validation, and fraud auditing. Strong evidence includes Makes assumptions explicit, answers the question asked, and explains both the benefit and cost of major decisions.