System requirements

Functional:

1. Users should be able to upload new events
2. The Platform should Delete the Old Events
3. Users should be able to search events in a geographic Area
4. Users Should be able to book tickets for a event if tickets available
5. Would need a Payment Gateway for Step 4. We will use a third Party Payment Gateway.

Non-Functional:

1. High Availability - The system should be highly available
2. Low Latency - The User experience should be as seamless as possible
3. High Scalability - The System should be able to support an ever increasing user base of client
4. 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,