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
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
// Endpoint to list all events
*Request :
GET /
// Endpoint specific events view
*Request :
GET /event/{event_id}
// Endpoint search events
*Request:
GET /search?keyword={keyword}&startDate={start_date}&endDate={end_date}
// Endpoints buy ticket
*Request :
POST /reserve
"tickets": [],
"user_id":
*Request :
POST /booking
"tickets": [],
"user_id":
payment_details" []
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
Relational DB - PostgresSQL
. Many relationships
. Consistence
. Reading > Writing (100:1)
. Low latency on esarch (read ~500ms)
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.