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}
// Endpoints buy ticket
*Request :
POST /reserve
"tickets": [],
"user_id":
*Request :
POST /booking
"tickets": [],
"user_id":
payment_details" []
Relational DB - PostgresSQL
. Many relationships
. Consistence
. Reading > Writing (100:1)
. Low latency on esarch (read ~500ms)