Requirements


Functional Requirements:


  • Users can see available shows.
  • Users can view a seating map to pick seats.
  • Users can view their purchased tickets in the app
  • Users can purchase tickets through app



Non-Functional Requirements:


  • PCI compliance for payments
  • High availability
  • Fast performance
  • Prevent double purchases
  • Prevent concurrent purchases
  • Scale to 100M users
    • 10M DAU
    • 100,000 QPS


API Design

GET /api/v1/shows: get all available shows

GET /api/v1/shows/{showId}/map: get seating map for show {showId}

GET /api/v1/profile/{profileId}/tickets: view tickets available to user

POST /api/v1/{showId}/checkout: purchase ticket for show {showId} -likely use strip/third party for processing

{

showId: '1234',

payment_details: {

card: '4567',

name: 'Joe Swanson',

sec_code: 999

}

}



High-Level Design

I propose a micro services architecture with 3 services, a payments service, booking service and a search service. I will first discuss the search service that will enable users to search available events near their area. An API gateway would route users to the /api/v1/shows endpoint and from here a search DB would be hit to see the available shows in the users area. For the most popular events, they would be stored in a redis cache as these would be frequently accessed across the platform. Next, the booking service would be responsible for the users actions of viewing the seat map, and routing users to the payment service. For extremely popular events, users would be put into a queue that would let a specified number of users in to be able to buy tickets for an event to reduce the amount of load on the service. Users that are in the queue would be processed into the booking service in a FIFO (first in first out) manner. Next, a user would select there seat from the map view which would update the Map DB to remove the specific seat that was selected while the users request would be put into a redis locking system with a certain time to live expiration to prevent concurrent booking. The first person to select the seat (down to milliseconds) would win and be granted a unique key with around 5-10 minutes to purchase the ticket before they are kicked out of the system. If the ticket is bought the Map DB would continue to show that the seat is removed, otherwise it would update the DB to show the seat is available again. Lastly the payment service, that is routed from the booking service would handle payments once a seat is selected. This would likely be an integration with a third party system like paypal or stripe and the transactions would be stored in a transaction DB with a hash function performed (like Sha-256) to ensure PCI compliance.



Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.