Ticket Booking: Latency Waterfall
Break down end-to-end latency by hop and percentile. Understand where the p99 tail comes from — DNS, network, cache lookup, database query, serialization. Real requests have wildly different paths depending on cache-hit location.
Latency Waterfall
Break down end-to-end latency by hop (network, application, database, cache) and percentile (p50/p90/p99/p99.9). Real requests have wildly different paths depending on cache-hit location — pick a scenario to see the full waterfall.
Amara Google 2009: every 100ms of latency = 1% revenue lost. Understanding WHERE the tail comes from is the difference between random optimization and targeted engineering.
Normal browse — event page (~85% of traffic)
User browses event page. Cached data, fast response.
HTML + basic event data cached.
Dynamic seat map with color-coded availability.
Aggregate: 'section A has 500 seats available'.
Optimize: Denormalized aggregate. Updated on write.
Client renders seat map.
Normal browse is **~100-400ms p99** — CDN + Redis dominate. **Fast browse is important** because most users leave without buying. Optimize for the browse UX first.
Bottleneck summary
Ticket booking has TWO dominant latency regimes: **normal browse (~200ms)** and **hot on-sale (hours of queue wait)**. Redis SETNX + TTL provides atomic seat holds. **The Waiting Room + wave release pattern is non-negotiable at Ticketmaster scale** — the Eras Tour collapse proved that infrastructure alone can't handle 14M concurrent for 2M items. **Throttle at the front door, prevent site collapse.**
Optimization tips (this architecture)
- **Redis SETNX + TTL seat holds**: 10min hold decouples selection from payment. TTL handles abandonment.
- **Waiting Room + wave release**: 10K users/60s. Prevents site collapse during hot on-sales.
- **Verified fan program**: Pre-registered users prioritized. Reduces bot competition.
- **Passive bot fingerprinting**: Known-good users skip CAPTCHA. Active challenge for high-risk.
- **WebSocket push for release**: Keep users engaged during long queues. Client-side timer for UX.
- **MULTI/EXEC for multi-seat holds**: All-or-nothing atomic hold across seat locks.
- **Denormalized availability**: Aggregate 'seats available in section A' for fast browse.
- **Postgres commit on payment success**: Convert Redis hold to durable ticket record.
Where to go next
Now that you can see where latency comes from, trace how the architecture EVOLVES to handle 10x more traffic. Or dive into the masterclass for the full ADR + business exercise + incident narrative.