Design Movie Ticket Booking System

Microsoft's "Design Movie Ticket Booking System" is a classic system design interview question emphasizing scalability for high-concurrency scenarios like peak booking times. It tests skills across distributed systems, concurrency control, data engineering, backend services, and infrastructure, often tagged with web and machine learning for features like recommendations. No single "official" full problem statement from Microsoft exists publicly, but it's commonly derived from standard formulations like those on GitHub, LeetCode discussions, and GeeksforGeeks equivalents (e.g., BookMyShow design).[1][2][4]

Problem Statement

Design an online movie ticket booking system (similar to BookMyShow or Fandango) that allows users to browse movies, view showtimes, select seats, book tickets, and make payments. The system must handle millions of concurrent users during peak hours (e.g., new movie releases), ensure no double-booking of seats, provide real-time seat availability, and scale globally. Key challenges include concurrency (multiple users booking the same seat), data consistency across distributed databases, and high throughput for searches and transactions.[2][4][6]

Functional Requirements

• User Actions: Register/login, search movies by location/time/genre, view theaters/showtimes/seat maps, select seats, book tickets, apply discounts, process payments, view booking history, cancel/refund tickets.
• Admin Actions: Manage movies, theaters, showtimes, seat inventory, promotions, and user bans.
• Additional Features: Email/SMS notifications, seat recommendations (ML-based on user history), waitlists for sold-out shows.[2]

Non-Functional Requirements

• Scale: 100M+ monthly users, 1M+ concurrent bookings, 10k+ tickets/sec peak.
• Concurrency: Atomic seat bookings to prevent overselling.
• Availability: 99.99% uptime, global distribution.
• Latency: <200ms for searches, <2s for bookings.
• Consistency: Strong for inventory/payments (ACID), eventual for recommendations.
• Security: PCI-compliant payments, JWT auth, rate limiting.[1][2]

Constraints

• Traffic: 500M daily queries, 10k QPS reads, 1k QPS writes.
• Storage: 10TB+ for user data, bookings, movie metadata; seats updated frequently.
• Concurrency Limit: Handle 10k+ simultaneous seat locks without conflicts.
• Data Retention: Bookings kept 1 year; hot data (next 7 days) in cache.
• Geographic: Multi-region (e.g., US/EU/Asia) with low-latency replication.[4][2]

Input/Output Examples

No formal I/O formats exist (it's not a coding problem), but typical API examples include:

| Endpoint | Input Example | Output Example | |----------|---------------|----------------| | /search/movies | { "city": "Chicago", "date": "2026-02-10", "genre": "Action" } | { "movies": [{ "id": 123, "title": "Avengers", "showtimes": ["18:00", "21:00"] }] } [2] | | /book/tickets | { "showId": 456, "seats": ["A1", "A2"], "userId": 789 } | { "bookingId": "BK789", "status": "confirmed", "qrCode": "xyz" } (succeeds if seats free; else "conflict") [4] | | /seats/availability | { "showId": 456 } | { "available": ["A3", "B1"], "total": 100, "booked": 50 } (real-time via cache) [2] |

Key Design Decisions

• Concurrency Handling: Optimistic locking (versioned seat inventory) + pessimistic locks (DB transactions) for holds; Redis for temp locks (30s timeout).[4]
• Databases: RDBMS (PostgreSQL) for bookings/users (sharded by theater); NoSQL (Cassandra) for logs; Redis for seat cache.[2]
• No ML-specific I/O examples found, but could involve /recommend returning { "seats": ["VIP"], "reason": "past prefs" }.[1]