Requirements


Functional Requirements:


  • Users can see available shows.
  • Users can view a seating map to pick seats.
  • Users can reserve/cancell reservation of a selected seating.
  • Users should be aple to process payment of a selected ticket and corresponding seatings;


Non-Functional Requirements:

  • Reliability - if user reserves or buy ticket it should be not available for other users;
  • Scalability - it should support small events as well as big events/parties concerts up to 100k people;
  • Availbility - system should available for the users 99.9% of time (especially when the reservation starts)



API Design


/GET getEvents()

/GET viewEvent(eventId : Int)

/PUT reserveTicket(userId : Int, eventId : Int, seatId : Int)

/PUT freeTicket(userId : Int, eventId : Int, seatId :Int)

/PUT buyTicket(userId: Int, eventId : Int, seatId : Int)


High-Level Design


I'll use the service TicketService which will connect to the DB; Regarding DB: because reservations/payments require atomicity we'll use the relational database here with the MessageQueue as a proxy between service/db so all the reservations/purchases are done in order and db is not overwhelmed by a lot of requests;


Because there can be very high load during the initial sale, service layer can be scaled independently and load balancer can be used before the service layer;


Ticket Service will comunicate with PaymentGateway to process payment of the tickets;



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.


Resrvation and purchase of tickets:


to either reserve or purchase ticket we have to make sure that ticket is in Availbale state


to speed up the reads and checks of ticket states we can use cache between tickets service and rdb to store reserved statets with its TTL in cacche;


if user wants to reserve ticket, first service checks cache; if it is not present in cache queue takes a job to reserve ticket - first job wins, at the end service updates cache;


if user want to buy ticket, first system tries to reserve ticket - if the step 1. suceed we can continue to purchase process; after all, cache is cleaned from that ticket;j


is user wants to free reservation it sends a job to queue, after all ticket reservation is cleaned from cache;