System requirements
Functional:
- Users should be able to upload new events
- The Platform should Delete the Old Events
- Users should be able to search events in a geographic Area
- Users Should be able to book tickets for a event if tickets available
- Would need a Payment Gateway for Step 4. We will use a third Party Payment Gateway.
Non-Functional:
- High Availability - The system should be highly available
- Low Latency - The User experience should be as seamless as possible
- High Scalability - The System should be able to support an ever increasing user base of client
- High Consistency - The system should show the latest data and should have ACID Properties
Capacity estimation
-> Server Estimations:
- Assume we have total 500M Active Users from which 100M are Daily Active Users
- If we assume at worst Case the QPS Received by the service = DAU and average QPS handled by the server = 64K
- Total Servers = 100 * 10**6 // 64000 ~= 1.7 * 10** 3= 1.7 K servers
-> Storage Estimations:
- Assume Everyday 1K new Events are added to the system.
- To store details about each event (including text, images, videos) we need average storage of say 100 MB
- So Daily Storage Requirements of the system can be something like this:
- 1 * 10 **3 * 100 * 10**6 Bytes = 100 * 10 **9 = 100 GB / Day
- Apart from this we would also need to store data about the Users of that platform as well.
API design
- uploadEvent (userID, metadata) - HTTP POST - metadata contains details about the event list the address of the event , ticket price, descriptions, date of the event, etc
- search (userID, searchText, metadata) - HTTP GET - metadata can contain specific types of events that the user might be interested in, It can also contain zipcode to search events in, etc
- showTickets (UserID, eventID) - HTTP GET - the different types of available tickets for the system are shown by the system
- bookTickets (userID, eventID, ticketType, quantity) - HTTP POST - Used by the user to book tickets for a selected event
Database Considerations
- We will be using a combination of Databases for this application.
- Data about the users and their bookings has be consistent also has a relation ship properties and have to maintain ACID properties. So we use Relational Databases like a MySQL or PostGress here.
- Any Images, Videos related to the events can be stores in a Blob Storage
- For the data related to the events (except Available Tickets) we can store in a Key Value Store database or even a document Databases (redis or mongo both can work for this)
- For tickets related data, because we want to avoid double booking or even overselling the events, we would want to use a database that supports ACID Properties. MySQL or postgress can be good options here.
Basic Building Blocks that we will be using
- Load Balancer
- Cache
- Relational database
- Key Value Store
- Blob Storage
- CDN
WorkFlows:
Add Event Workflow:
- A User talks to the system through a Load Balancer.
- the Upload Event service creates a new event in the system looking at the metadata provided by the user.
- There is a service called as "Delete Events". At the time of adding a new event, we also add details about the time when this event is supposed to be deleted by the system at a future date.
Search Workflow:
- The User inputs data about the search parameters for the system.
- The system has a "Get Events" service which looks at the input metadata, tries to find the events that the user might be interested in.
Booking Workflows:
- The User selects the event which has available tickets and books the tickets,