Scaling an Event Ticketing System

An event ticketing system is one of the most challenging distributed systems to design. When tickets for a popular concert go on sale, the system must handle massive traffic spikes, guarantee zero overselling of limited inventory, and deliver sub-second response times under extreme load. This course section explores the architecture, strategies, and trade-offs involved in scaling such a system from thousands to millions of concurrent users.

At its core, a ticketing system faces a fundamental tension: high read throughput (users browsing events) versus strict write consistency (reserving specific seats). The CAP theorem tells us we cannot have all three properties simultaneously — and in ticketing, consistency is non-negotiable. You cannot sell the same seat to two people.

The diagram above illustrates the two-path architecture — a common pattern in ticketing systems where reads and writes follow separate pipelines. Reads are served from cached data with eventual consistency, while writes go through a serialized path that guarantees inventory integrity.

Key Scalability Challenges

Footnotes

1. Gilbert, S. & Lynch, N. "Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services" — ACM SIGACT News, 2002. The CAP theorem's formal proof establishing that consistency and availability cannot both be guaranteed during network partitions. ↩

2. Kleppmann, M. "Designing Data-Intensive Applications" O'Reilly, 2017 — Chapter on derived data and the lambda architecture pattern for separating read/write paths. ↩

Core Architectural Components

1. Load Balancing & Traffic Management

At the edge, a Global Server Load Balancer routes users to the nearest data center. Behind it, L7 load balancers distribute requests across API server pools.

For ticketing, weighted round-robin with connection draining is preferred over least-connections. The reason: during a sale, new servers spinning up shouldn't immediately receive reservation requests until their local caches are warm.

2. Caching Strategy

The read path for ticketing is overwhelmingly dominant — 95%+ of requests are users browsing events, viewing seat maps, or checking availability. A multi-tier caching strategy is essential:

• L1 — Browser Cache: Static event data, images, and venue maps served with Cache-Control headers
• L2 — CDN Edge Cache: Event listings, pricing tiers cached at edge nodes; TTL set to 30–60s during live sales
• L3 — Application Cache (Redis): Seat availability maps, event metadata; updated on every reservation via cache invalidation
• L4 — Database Query Cache: Frequent queries for event lists, venue details

During a high-demand onsale event, cache hit ratios must stay above 90% for the system to survive. Every cache miss that reaches the database adds latency and load.

3. The Inventory Problem — Preventing Overselling

This is the hardest problem in ticketing systems. You have $N$ seats for an event and $10N$ concurrent buyers. Solutions include:

Pessimistic Locking (Row-Level)

Traditional approach using SELECT ... FOR UPDATE. Simple but creates severe lock contention under high concurrency.

Optimistic Concurrency Control

Use version columns: UPDATE seats SET version=version+1, status='reserved' WHERE id=X AND version=V. If zero rows affected, the seat was already taken — retry or fail.

Distributed Locking (Redis-based)

Use SETNX (SET if Not eXists) to atomically claim a seat in Redis, then persist to database asynchronously. This makes the Redis cluster the source of truth for availability during the sale.

Queue-Based Reservation

All reservation requests enter a message queue. A single-threaded consumer processes reservations sequentially per event, guaranteeing no conflicts. This is the approach used by large-scale systems.

$\text{Throughput}_{\text{queue}} = \min\left(\frac{N_{\text{consumers}}}{t_{\text{process}}}, \frac{N_{\text{partitions}}}{t_{\text{partition}}}\right)$

Where $N_{\text{consumers}}$ is the number of consumer instances, $t_{\text{process}}$ is the processing time per reservation, and $N_{\text{partitions}}$ is the Kafka partition count (one per event).

Footnotes

1. Nginx documentation on load balancing algorithms and connection draining: https://docs.nginx.com/nginx/admin-guide/load-balancer/ ↩

2. Redis Labs case study on ticketing system caching patterns — "Achieving 99.9% Cache Hit Ratio During Peak Load" — demonstrating multi-tier caching in high-concurrency event systems. ↩

3. Kafka documentation on exactly-once semantics and partition-based ordering: https://kafka.apache.org/documentation/ — Using one partition per event to serialize all seat reservation operations, preventing concurrency conflicts. ↩

Handling Flash Sales — The Queue-Based Approach

The most robust pattern for extreme scale is virtual queuing — made famous by systems like Queue-it and used by Ticketmaster during onsales. Instead of letting all users hit the reservation service simultaneously, they enter a waiting room:

The key parameters for virtual queuing:

The drain rate $r$ is calculated based on the reservation service capacity $C$ and average purchase time $T$:

$r = \frac{C}{T} \times \text{safety\_factor}$

For example, if the reservation cluster can handle 5,000 concurrent sessions and the average purchase takes 5 minutes, then:

$r = \frac{5000}{300\text{s}} \times 0.8 = 13.3 \text{ users/sec}$

This is deliberately conservative — a safety factor of 0.8 prevents the system from becoming saturated.

Footnotes

1. Queue-it virtual waiting room technology — used by Ticketmaster and other major ticketing platforms to manage flash sale traffic. See: https://queue-it.com/ ↩

Database Architecture & Sharding Strategy

The database layer is where consistency meets scale. For a ticketing system, we use a hybrid approach — different database technologies for different access patterns:

Primary Database: PostgreSQL (OLTP)

PostgreSQL with serializable isolation level for all reservation and payment operations. Key optimizations:

• Partition events by date range — old events are archived to cold storage
• Index heavily on (event_id, seat_status) for availability queries
• Use advisory locks for event-level operations: pg_advisory_lock(event_id) serializes all seat modifications for a given event in one DB node

Sharding Strategy

For global scale, shard by event_id using hash-based sharding:

$\text{shard} = \text{hash}(event\_id) \mod N_{\text{shards}}$

This ensures all seats for a single event live on the same shard, eliminating cross-shard transactions for the common case of "reserve seat for event X." The shard count $N_{\text{shards}}$ should be set to 2× the number of physical DB nodes to allow for future resharding via consistent hashing.

Event Sourcing for Audit Trail

Every state transition in the ticketing lifecycle is stored as an event record:

This event log enables perfect auditability — critical for the ticketing industry where disputes, fraud detection, and regulatory compliance require a complete history.

Footnotes

1. Vogels, W. "Eventually Consistent" — ACM Queue, 2009. Discussion of consistent hashing and its role in minimizing data movement during resharding operations in distributed systems. ↩

Real-World Capacity Planning

Based on industry data from large-scale ticketing platforms:

Capacity planning must account for the worst-case concurrent write throughput:

$W_{\text{peak}} = \frac{U_{\text{concurrent}} \times R_{\text{reservation\_rate}}}{1 - A_{\text{abandonment}}}$

Where $U_{\text{concurrent}}$ is peak concurrent users, $R_{\text{reservation\_rate}}$ is the fraction of users attempting to reserve per second (~5%), and $A_{\text{abandonment}}$ is the hold abandonment rate. For 1M concurrent users:

$W_{\text{peak}} = \frac{1{,}000{,}000 \times 0.05}{1 - 0.20} = 62{,}500 \text{ reservations/sec (attempted)}$

With a virtual queue draining at 50 users/sec and 80% converting to reservations:

$W_{\text{actual}} = 50 \times 0.80 = 40 \text{ reservations/sec}$

This is why virtual queuing is essential — it reduces the write load from 62,500/sec to 40/sec, a 1500× reduction.

Footnotes

1. Ticketmaster Verified Fan program data and industry reports on bot traffic during major onsales — including analysis of the Taylor Swift Eras Tour onsale incident and subsequent congressional testimony. ↩