System requirements

Functional:

• User Registration: Users should be to register as passengers or drivers, providing necessary personal information such as name, contact details, and payment information.
• Matching Algorithm: Develop an algorithm to efficiently match passengers with nearby drivers based on factors like location, availability, and ride preferences.
• Ride Request: Passengers should be able to request rides by specifying their current location, destination, and preferred vehicle type (e.g., sedan, SUV).
• Real-time Tracking: Passengers should be able to track the location of their assigned driver in real-time until reaching the destination.
• Payment Processing: passengers should be able to make secure payments for their trips, It should support various payment methods like credit/debit cards, digital wallets, and cash.
• Rating System: Passengers and drivers should be able to provide feedback on ride experiences, helping maintain service quality and accountability.
• Notifications: Users should receive timely notifications regarding ride status updates, driver arrival, payment confirmation, and other relevant information.
• Messaging: Passengers and drivers should be able to message each other when the trip has been booked.  

Non-Functional:

• Performance: Ensure the platform can handle a high volume of concurrent users and requests efficiently, with minimal latency in matching, tracking, and payment processing.
• Scalability: Design the system to scale horizontally to accommodate increasing user demand and geographical expansion without compromising performance.
• Reliability: Maintain high system availability to ensure users can access the platform and request rides reliably at any time, with minimal downtime or service interruptions.
• Security: Implement robust security measures to protect user data, prevent unauthorized access, and ensure the integrity and confidentiality of all transactions and communications.

Capacity estimation

Consider the below assumptions

• Total user base of 5 million users and 200000 drivers
• We have 1 million rides daily
• User performs 5 actions on an average

With the above assumptions, let's answer the below question

How many requests do we need to handle every day?

Since we have 1 million daily users and each user makes 5 requests.

Total requests = daily active users * number of requests per user

Total requests = 1 million * 5 requests

Total requests = 5 million requests

How many Requests per Second (RPS)?

Total number of requests daily = 5 million requests (assuming each user performs 5 actions daily)

Therefore, requests per second (RPS) can be calculated as follows:

RPS = Total requests per day / Number of seconds in a day

RPS = 5,000,000 / 86,400 seconds (24 hours * 60 minutes * 60 seconds)

RPS ≈ 57.87

So, the system needs to handle approximately 58 requests per second on average.

How much storage do we need per day?

Each message is assumed to be about 500 bytes.

Total storage needed daily can be calculated as:

Daily storage = Total daily messages * Average message size

Daily storage = 5 million messages * 500 bytes per message

Daily storage = 2,500,000,000 bytes

Converting bytes to gigabytes (GB):

1 GB = 1,073,741,824 bytes

Therefore, Daily storage ≈ 2.33 GB

So, the system needs approximately 2.33 gigabytes of storage every day to accommodate the messages generated.

API design

1. User Registration API
2. Description: Allows users to register as passengers or drivers on the platform.
3. Input: User details (name, contact info, payment info) and role (passenger/driver).
4. Output: Success/failure status indicating whether the registration was successful.
5. Ride Request API
6. Description: Enables passengers to request rides by providing their current location, destination, and preferred vehicle type.
7. Input: Passenger location, destination, preferred vehicle type.
8. Output: Confirmation of ride request with details such as driver assignment and estimated time of arrival.
9. Driver Availability API
10. Description: Allows drivers to update their availability status (online/offline) on the platform.
11. Input: Driver ID and availability status.
12. Output: Confirmation of availability status update.
13. Real-time Tracking API
14. Description: Provides real-time location tracking of assigned drivers to passengers.
15. Input: Ride ID or driver ID.
16. Output: Continuous updates of driver's current location until reaching the destination.
17. Payment Processing API
18. Description: Facilitates secure payment transactions between passengers and drivers.
19. Input: Payment details (amount, method, transaction ID).
20. Output: Confirmation of payment completion and transaction ID.
21. Rating and Feedback API
22. Description: Allows passengers and drivers to rate and provide feedback on each ride.
23. Input: Ride ID, user ID, rating, and optional feedback.
24. Output: Confirmation of rating submission and any applicable incentives or penalties.
25. Notification API
26. Description: Sends timely notifications to users regarding ride status updates, driver arrival, and payment confirmation.
27. Input: User ID, notification type, and relevant ride/payment details.
28. Output: Delivery status of the notification.
29. Ride Fare Estimation API
30. Description: Provides an estimated fare for a ride based on the distance between the pickup and drop-off locations and the selected vehicle type.
31. Input: Pickup location, drop-off location, preferred vehicle type.
32. Output: Estimated fare for the ride.
33. Chat API
34. Description: Initiates a chat conversation between a passenger and the assigned driver for communication purposes.
35. Input: Ride ID or user IDs of the passenger and driver.
36. Output: Confirmation of the chat initiation and a unique identifier for the chat session.

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design...

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?