Katkat
Back

Design an online ticket booking system

MicrosoftSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

This question tests the ability to design a distributed system that manages high-concurrency inventory, specifically focusing on consistency models, race condition prevention during seat selection, and reliable payment processing.

Design an Online Ticket Booking System

Design a scalable backend system for an online platform that allows users to browse events, select seats, and purchase tickets. The system must handle high traffic during popular event launches and ensure that no two users can book the same seat simultaneously.

Requirements

Functional Requirements:

  1. Users can view a list of events and see seat availability.
  2. Users can select seats and hold them for a limited time (e.g., 10 minutes) before purchasing.
  3. Users can complete a payment to confirm their ticket purchase.
  4. If the payment is not completed within the hold time, the seat is released back to the inventory.

Non-Functional Requirements:

  1. Consistency: Strong consistency is required for seat inventory; overbooking must be impossible.
  2. Scalability: The system must handle massive spikes in traffic during "on-sale" events (e.g., 100k requests per second).
  3. Availability: High availability for browsing; graceful degradation is acceptable during peak demand.
  4. Auditability: Every transaction must be logged to prevent fraud and reconcile inventory.

Deliverables

  1. High-level architecture diagram (described in text).
  2. API design for seat selection and booking.
  3. Database schema choices (SQL vs. NoSQL) and why.
  4. Strategy for handling concurrency during the booking flow.

Hints

Hint 1

Consider using a distributed locking mechanism or a database-level atomic operation to ensure only one user can claim a specific seat ID.

Hint 2

Decouple the booking process into a state machine: Available -> Held -> Confirmed/Expired.

Hint 3

For high-traffic events, consider using a message queue or a wait-room pattern to smooth out incoming request bursts before hitting your database.

Follow-up questions

  • How would you handle a situation where the payment gateway service is slow or intermittent during a checkout process?
  • How would you optimize the system for users querying the seat map to reduce load on the primary inventory database?
  • If a user refreshes the page, how do you ensure their existing 'held' seat state is recovered correctly?