E-CommerceStaff Level

Ticketmaster High-Concurrency Concert Ticketing

Q: How do you prevent a user from hoarding seats using multiple browser tabs?

Queue position tokens are bound to authenticated user IDs and device fingerprints, allowing only one active reservation transaction per account.

Q: What happens if the payment gateway times out after a seat hold expires?

The saga coordinator checks the transaction status with the payment processor. If funds were captured, it attempts seat allocation; if unavailable, it issues an immediate automated refund.

Handle viral stadium concert ticket drops with virtual waiting rooms, seat reservation locks, and anti-scalping defenses.

Practice in ClawPad Desktop ← All System Design Problems

Target Scale

Engineering Scale & Performance SLAs

Target production parameters expected in a senior or staff interview round.

Peak Throughput

100,000 Checkout Requests/sec

Sustained peak request volume during high-traffic events.

Active Users

10 Million Spike Visitors

Daily active users generating read and write operations.

Storage Ingestion

50 GB event transaction data

Projected data ingestion and replication storage capacity.

Latency Budget

Seat lock confirmation < 100ms

Strict end-to-end percentile latency SLA constraint.

Stage 01

Functional & Non-Functional Requirements

Establish clear problem boundaries before proposing architectural components.

Functional Scope

Core System Capabilities

Browse concert events, venues, and interactive seat maps.
Hold selected seats for 10 minutes during checkout.
Complete payment and release unsold seats back to inventory on timeout.
Enforce max 4 tickets per customer and anti-bot verification.

Non-Functional Scope

Reliability & Latency SLAs

Strict consistency: zero double-booking under any concurrency load.
Virtual waiting room fair ordering (FIFO token bucket) to protect database.
High availability for general catalog browsing even during viral stadium onsales.

Stage 02

Capacity Estimation Math

Step-by-step arithmetic conversions for QPS, storage, and bandwidth.

Dimension	Calculation Formula	Estimated Result
On-Sale Traffic Ingress	100,000 users attempting to click 'Reserve' at exact onsale second	100,000 concurrency spike
Stadium Inventory Constraints	60,000 total stadium seats / 4 seats per order = 15,000 orders	15,000 total successful transactions
Database Load Protection (Queue Rate)	Database write ceiling 500 TPS -> Admit 500 users/sec from waiting room	30-second total queue drainage window

Stage 03

Multi-Tier Architecture & Component Topology

How requests navigate ingress gateways, application logic, caching, and persistence.

Virtual Waiting Room (Edge Gate)

Cloudflare Workers / CloudFront Functions · Redis Queue (ZSET) · Fair Queuing Engine

Hold excess traffic outside core infrastructure, assign cryptographic queue position tokens, and admit users at a controlled rate.

Seat Reservation & Inventory Tier

Reservation Service · Redis Seat State Cluster · Distributed Redlock

Atomically mark seats 'RESERVED' with 10-minute TTL; return 409 Conflict if already held.

Booking & Payment State Machine

Booking Orchestrator · Stripe Payment Gateway · Saga Coordinator

Process credit card transactions, transition booking from PENDING to CONFIRMED, and emit digital barcode tickets.

Expiration & Reconciliation Worker

TTL Expiration Consumer · Kafka Dead-Letter Queue · Postgres Seat Inventory

Listen to Redis key expiration events and release expired reservations back into the venue pool.

Stage 04

Database Schemas & Partitioning Strategy

Entity models, indexing, and primary key partitioning.

Table: seats

PK: seat_id

seat_id (UUID PK)
event_id (UUID)
section (VARCHAR(32))
row (VARCHAR(8))
seat_number (INT)
status (ENUM: AVAILABLE, RESERVED, SOLD)
version (INT)

Composite index on (event_id, status) for real-time seat availability map rendering.

Table: seat_holds

PK: hold_id

hold_id (UUID PK)
seat_id (UUID)
user_id (UUID)
expires_at (TIMESTAMP)
created_at (TIMESTAMP)

Unique constraint on seat_id; TTL index on expires_at for reaper cleanup.

Table: orders

PK: order_id

order_id (UUID PK)
user_id (UUID)
event_id (UUID)
total_amount_cents (INT)
status (VARCHAR(32))
created_at (TIMESTAMP)

Index on user_id for customer ticket wallet lookup.

Stage 05

Critical Architectural Trade-Offs

How to defend engineering compromises when challenged by interviewers.

Decision Point

Seat Hold Concurrency: Database Row Locks vs Distributed Redis Locks

Option A: Database Pessimistic Locking (`SELECT FOR UPDATE`)

Option B: In-Memory Redis Distributed Locks with Optimistic DB Commit

Rationale: Pessimistic database locking causes massive connection pool exhaustion at 100k QPS. In-memory Redis locks handle atomic reservation in <2ms, with the relational database only processing confirmed checkouts.

Decision Point

Waiting Room: Client Polling vs Server-Sent Events (SSE)

Option A: Client HTTP Polling every 3 seconds

Option B: Server-Sent Events (SSE) Push

Rationale: SSE maintains a single lightweight HTTP connection per queued user, eliminating millions of redundant polling requests while notifying admitted users with zero delay.

Technical FAQ

Frequently Asked Questions: Ticketmaster High-Concurrency Concert Ticketing

Key interview questions and conceptual defenses.

How do you prevent a user from hoarding seats using multiple browser tabs?