Loading...
1 - View events: Users must be able to view the platform available events
2 - Search for events: Users must be able to search for specific platform events
3 - Buy tickets: Users must be able to buy tickets to get access to these events
1 - System must attend 10 Million active user simultaneously on periods preceding big events
2 - System must avoid buying bots from buying multiple ticket of big events and cannot promote benefits for user located in priviledges geolocations
3 - The search for events must be inteligent, tolet typing errors (typo) and find words for similarity
(Stemming) ex: Search = house | Results = houses, housing, housed etc ...
4 - System must avoid that two users buy the same seat for same event (CONSISTENCE - CONCURRENCY)
5 - System must have low latency during search for events (<500ms)
6 - System must be able to provide a high read transfer rate (100:1)
7 - System must operate in high availability mode
DB capacity - not a big deal as the change in number of events does not happen so fast, and the event data size is not variable.
Data transfer is quitely constant per user - events list and inidividual event details
// Endpoint to list all events
*Request :
GET /
// Endpoint specific events view
*Request :
GET /event/{event_id}
// Endpoint specific events creation
*Request :
POST /event/{event_id}
// Endpoint specific events update
*Request :
PUT /event/{event_id}
// Endpoint specific events deletion
*Request :
DELETE /event/{event_id}
// Endpoint search events
*Request:
GET /search?keyword={keyword}&startDate={start_date}&endDate={end_date}
// Endpoint to list event's seats availability
*Request:
GET /event/{eventid}/seats
// Endpoints buy ticket - reservation
*Request:
POST /reserve
"tickets": [],
"user_id":
// Endpoint buy ticket - booking and client notification
*Request:
POST /booking
"tickets": [],
"user_id":
payment_details" []
Relational DB - PostgresSQL
. Many relationships
. Consistence
. Reading > Writing (100:1)
. Low latency on esarch (read ~500ms)
Detailed Component Design
API Gateway will handle:
Load Balancer: distribute the calls to different microservices based on endpoint - Search, Event or Booking services. Allows individual service's escalation, improves performance.
Redirects to Cloudfare - avoid DDoS, Bots and Geolocation privileges.
Redirect to CDN - static content will be globally replicated to improve performance.
Elastic Search
implements Full Text Search with inverted index search allowing fast read. Updated with DB data by CDC.
Booking service
Reservation - set a flag 'reserved' for a short TTL (Time-to-leave - e.g. 5 min). This will avoid another user to book that same event's seat. After TTL, if seat is not booked, the status is reset to 'available'.
Booking - will confirm the booking setting that seat as 'booked' in database.
Connects to external Payment API to process payment.
Event Service
Responds requests to list and show details of events with seating view including current availability.
Handles reservation updates.
Keeps in cache least frequently accessed records, and reservation status
User flow
1- User firstly opens main page (endpoint GET /) which calls the list of main events with pagination and sorted by most searched events. Load Balancer redirects to Event Service which gets the list from Cache. When Cache is empty, shows no event.
2- When user searches for an event (endpoint GET /search), it reads from Database for keyword similarity and event date range. Searchervice is responsible to reach data using ElasticSearch, which is populated with indexation by CDC - updated from Database based on changes.
3- When an specific event is selected for details (endpoint GET /event/{eventid}/), it gets all details about that event. All seats are listed, with status available, reserved or booked. EventService get details from Database and updates status reserved for those seats found in Redis TTL. Redis Cache is updated with this event. Administrators only have permission to call same endpoint with HTTP verbs POST, PUT and DELETE to create, update and delete events respectively.
4- When user starts booking a seat of an event, a reservation is send. BookingService sends reservation to Redis with Time-to-leave (e.g. 5 min).
5- When user wants to complete booking, it is redirected to payment and sends the payment information. Once confirmed the booking is finished. BookingService send payment info to PaymentService, if payment is confirmed by External Payment API then PaymentService sends response back to BookingService - this communication is made by WebSocket. After confirmation NotificationService is triggered to send asyncronous advise to user.
Outages are mitigated by keeping a minimal number of replicas on multiple geographies.
Peak times will be handled with Redis Cache data and Auto scale of the services replicas according to the demand. After a limit of accesses, users are redirect to Cloudfare to a queue, and redirected to main page after the user position in the queue is reached.