In this issue, I walk through the exact thinking I’d use in a system design interview out loud, step by step. Clear, practical, and including trade-offs you can defend.
What you’ll learn in ~15 minutes
How I would scope the problem without missing important requirements (custom aliases, expirations, availability).
Why Redis distributed locks with TTL beat database-level locking for ticket reservations - and the elegant fallback strategy when Redis crashes
The counter-intuitive approach to handling 1M concurrent users during Taylor Swift concerts
How to architect different consistency guarantees within the same system - strong consistency for bookings, eventual consistency for search, and why this hybrid approach is crucial
How this issue is structured
I split the write-up into the same sections I’d narrate at a whiteboard. Free readers get the full walkthrough up to the deep-dive parts. Paid members get the 🔒 sections.
Initial Thoughts & Clarifying Questions
Functional Requirements
Non-Functional Requirements
Back-of-the-envelope Estimations (QPS, storage, bandwidth, cardinality math)
🔒 High-level System Design (and the excalidraw link for it!)
🔒 Component Breakdown (why each piece exists + alternatives)
🔒 Trade-offs Made
🔒 Security & Privacy
🔒 Monitoring, Logging, and Alerting
🔒 Final Design (and the excalidraw link for it!)
Quick note: If you’ve been getting value from these and want the full deep dives, becoming a paid member helps me keep writing—and you’ll immediately unlock the 🔒 sections above, plus a few extras I lean on when I practice.
Members also get
12 Back-of-the-Envelope Calculations Every Engineer Should Know
My Excalidraw System Design Template — drop-in canvas you can copy and tweak.
My System Design Component Library
Let’s get to it!
Initial Thoughts & Clarifying Questions
To begin, I'd want to understand the exact scope and constraints of this ticket booking system. Here are the key questions I'd ask the interviewer:
1. "What's the scale we're designing for?" My assumption: We're building for a large-scale platform handling millions of users globally. I'd estimate 10-100 million monthly active users, with significant traffic spikes during popular events. This tells me we need to design for elasticity from day one.
2. "Are we handling the full user journey or focusing on specific parts?" My assumption: We're focusing on the consumer-facing booking flow (search, view, book) rather than the admin side (adding events, managing venues). This lets me narrow my design to the most critical user paths.
3. "What types of events are we supporting?" My assumption: Everything from small theater shows to massive stadium concerts and sporting events. This means our venue sizes could range from 100 seats to 100,000+, which impacts how we handle seat selection and availability.
4. "How do we handle payment processing?" My assumption: We'll integrate with third-party payment providers like Stripe rather than building our own payment infrastructure. This is standard practice and removes significant complexity from our design.
5. "What's the ticket reservation model?" My assumption: Similar to existing platforms, users can temporarily reserve tickets (say, 10 minutes) while completing payment. This prevents others from booking the same seat during checkout but releases it if the purchase isn't completed.
6. "Are there any specific consistency requirements?" My assumption: Absolutely critical - we can never double-book a seat. This is non-negotiable and will drive many of our technical decisions around data consistency and locking mechanisms.
7. "Do we need to support features like ticket transfers or resales?" My assumption: These are out of scope for the initial design. We're focusing on the primary booking flow, though our architecture should be extensible enough to add these features later.
Functional Requirements
From what I understand, the core requirements are:
Search for events - Users need discovery mechanisms to find events by various criteria (artist, venue, date, location). This is the entry point to our funnel, so it needs to be fast and intuitive.
View event details - Display comprehensive information including venue details, seating charts, available tickets, and pricing. Users make purchase decisions here, so accuracy and real-time updates are crucial.
Book tickets - The critical transaction flow where users select seats, reserve them temporarily, and complete payment. This is where our consistency guarantees matter most.
I'm deliberately keeping this narrow. Features like user accounts, order history, and ticket delivery are important but secondary to nailing the core booking flow.
Non-Functional Requirements
I'd expect this system to handle some unique challenges:
Consistency vs. Availability Trade-offs: I need strong consistency for the booking flow - we absolutely cannot sell the same seat twice. But for search and browsing, I'd prioritize availability. If our search service goes down during a Taylor Swift ticket release, we've failed. So I'm making a nuanced choice: strong consistency for bookings, high availability for discovery.
Flash Traffic Patterns: We'd likely need to handle 100,000+ requests per second during popular event releases. Normal traffic might be 1,000 QPS, but when famous artists’ tickets drop, we could see 100x spikes within seconds. Our architecture needs to handle this gracefully without falling over.
Read-Heavy Workload: I'd expect a 100:1 read/write ratio, maybe even 1000:1. For every ticket purchased, hundreds of users are browsing, searching, and checking availability. This heavily influences our caching and database strategies.
Real-time Seat Availability: Sub-second updates are critical. When I'm looking at a seat map for a popular event, I need to see seats disappearing in real-time, or users will have a frustrating experience clicking on already-taken seats.
Geographic Distribution: Events are location-specific, so we can leverage geographic partitioning. Users in London primarily search for London events, so keeping that data close reduces latency.
Back-of-the-Envelope Estimations
Let's work through the numbers to understand our scale:
User Activity: "Let's say we have 10 million daily active users... If each user searches for 5 events per day and views 2 in detail, that gives us:
Search QPS: 10M × 5 / 86,400 ≈ 580 searches/second
Event view QPS: 10M × 2 / 86,400 ≈ 230 views/second
Note: During major releases, we might see 1 million concurrent users trying to buy tickets for the same event. That's potentially 10,000+ booking attempts per second for a single event!"
Storage Requirements: "If we have 100,000 venues globally, with an average of 10 events per venue per month:
Events per year: 100,000 × 10 × 12 = 12 million events
Average tickets per event: 5,000 (mix of small and large venues)
Total tickets: 12M × 5,000 = 60 billion tickets/year
Storage per ticket: ~500 bytes (ID, status, price, metadata)
Annual ticket storage: 60B × 500B = 30TB
Actually, let me reconsider that... tickets are ephemeral. Once an event passes, we can archive that data. So our hot storage needs are much lower - maybe 1-2TB for upcoming events."
Bandwidth Estimates: "For the seat map alone, if we're sending 5,000 seat positions and availability status:
Seat map size: 5,000 seats × 50 bytes = 250KB
During peak (1M concurrent users): 250KB × 1M = 250GB
But with proper caching and CDN distribution, actual origin bandwidth is manageable"
Memory Requirements: "For our distributed lock system handling reservations:
Active reservations during peak: 100,000 concurrent
Memory per reservation: 100 bytes
Total memory needed: 10MB - trivial for Redis!"
🔒 System Design
Here’s the whiteboard walk-through I’d narrate: