Design Ticketmaster / Concert Booking

Meta's "Design Ticketmaster / Concert Booking" interview question focuses on building a scalable ticketing system handling high concurrency, like popular concert sales (e.g., Taylor Swift events). It emphasizes preventing double bookings while ensuring low-latency search and availability during peak loads.[1][3]

Problem Statement

Design a system like Ticketmaster for users to search events (by artist, location, genre), view details and seat maps, reserve seats, and confirm bookings without overselling. Core challenges include spiky traffic (millions of concurrent users), strong consistency for bookings, and high availability for reads. Functional priorities: (1) Book tickets, (2) View events/seats, (3) Search events. Non-functional: Handle 10M+ concurrent requests, sub-second latency, no double bookings.[3][5][1]

Key Requirements

• Functional: Search/view events, seat selection with real-time availability, two-phase booking (reserve → confirm), user accounts, payments.[2][1]
• Non-Functional: 99.99% uptime, scale to 10M QPS peaks, <200ms search latency, strong consistency (no oversell), fault-tolerant.[1][2]
• No explicit ML tags in core problem, but advanced versions discuss dynamic pricing or fraud detection.[2]

Constraints & Scale

• Peak: 10M concurrent users for hot events (e.g., 100K tickets sell out in minutes).[3][1]
• QPS: 10K-100K steady, spikes to 10M for views/bookings.[1]
• Seats per event: 10K-100K. Storage: Billions of events/tickets historically.[2]
• Bandwidth: 100GB/s+ during sales.[1]

Input/Output Examples

No formal I/O formats given; examples are API-like from breakdowns.[1]

| API Endpoint | Method | Input Example | Output Example | |--------------|--------|---------------|----------------| | Search Events | GET /events | ?artist=taylor+swift&location=NYC&date=2026-02-10 | [{id:1, name:"Eras Tour", venue:"MSG", seats_available:5000, date:"2026-02-10"}] [1][3] | | View Event | GET /events/{id}/seats | ?section=general | Seat map JSON: {rows: [...], available: [true,false,...]} [1] | | Reserve Seats | POST /reservations | {event_id:1, seats:[A12,A13], user_id:123, timeout:10min} | {reservation_id:xyz, expires:2026-02-02T04:26:00Z, status:"held"} [1][5] | | Confirm Booking | POST /bookings | {reservation_id:xyz, payment:{...}} | {booking_id:abc, tickets:[...], total:$250} [1] |

Design Highlights

High-level: Load balancers → App servers → Search (Elasticsearch) for reads, Booking service with distributed locks (Redis) for reserves, SQL (sharded Vitess) for consistency. Use optimistic locking or 2PC for no double-books; cron cleans expired holds.[2][1]