OneNoughtOne
0/86
Loading content...
Design an online ticket booking platform like BookMyShow or Fandango where users can browse movies/events, view available seats on a real-time seat map, select and temporarily hold seats, complete payment, and receive confirmed e-tickets — all while guaranteeing that no two users can ever book the same seat.
| Metric | Value |
|---|---|
| Registered users | 100 million |
| Daily active users (DAU) | 10 million |
| Events listed | 50,000 (movies, concerts, plays, sports across cities) |
| Shows per day | 500,000 (across all cinemas and venues) |
| Seats per show (average) | 250 |
| Total seat inventory per day | 125 million seats |
| Bookings per day | 5 million |
| Peak bookings per minute (popular release) | 50,000 |
| Concurrent seat-map viewers (popular show) | 50,000+ |
| Seat hold TTL | 8 minutes |
No double-booking: Absolute guarantee — the same seat for the same show is NEVER sold twice; enforced via atomic DB transitions + distributed locks
Low latency: Seat map loads in < 200ms; seat hold response in < 100ms; payment flow completes in < 10 seconds
Surge resilience: Virtual waiting room for popular shows; rate limiting per show; read replicas for seat map display; system handles 50K bookings/min without degradation
Real-time seat map: Seats held/booked by others reflected on all viewers' seat maps within 2 seconds via WebSocket
Payment reliability: Idempotent payments; automatic seat release on payment failure/timeout; webhook + polling for payment confirmation
Availability: 99.99% uptime; graceful degradation (show cached seat map if DB is slow; queue bookings if payment gateway is slow)
Browse events: users can browse movies, concerts, plays, and sports events — filtered by city, genre, language, date, and venue
View seat map: for a selected show (movie + cinema + showtime), display a real-time seat map showing available, booked, and temporarily held seats
Seat selection and temporary hold: when a user selects seats, temporarily hold them for a limited time (e.g., 8 minutes) to prevent double-booking while the user completes payment
Booking and payment: complete seat reservation atomically with payment; on successful payment, confirm the booking and issue an e-ticket; on failure or timeout, release the held seats
No double-booking: guarantee that the same seat for the same show is never sold to two different users — even under high concurrency (e.g., popular movie opening night)
Search: full-text search across event names, actors, directors, venues; auto-suggestions and filters
Reviews and ratings: users can rate and review movies/events; aggregate ratings displayed on event pages
Cancellation and refund: users can cancel bookings within a policy window; initiate refund to original payment method
Notifications: send booking confirmation, e-ticket, showtime reminders (1 hour before), and offer/promotion notifications via email/push/SMS
Analytics for venue partners: dashboard showing occupancy rates, revenue, popular showtimes, and demand forecasting per venue/screen
Non-functional requirements define the system qualities critical to your users. Frame them as 'The system should be able to...' statements. These will guide your deep dives later.
Think about CAP theorem trade-offs, scalability limits, latency targets, durability guarantees, security requirements, fault tolerance, and compliance needs.
Frame NFRs for this specific system. 'Low latency search under 100ms' is far more valuable than just 'low latency'.
Add concrete numbers: 'P99 response time < 500ms', '99.9% availability', '10M DAU'. This drives architectural decisions.
Choose the 3-5 most critical NFRs. Every system should be 'scalable', but what makes THIS system's scaling uniquely challenging?
The complete explanation is included with Career and All Access. Compare it with your approach once you’ve worked through the problem.
Your system-design submission history is available after you sign in.
Sign In