Requirements for Uber Design
Understand the requirements to design Uber service.
Let’s start with the requirements for designing a system like Uber.
Functional requirements
Following are the functional requirements that we will focus on while designing Uber:
-
Update driver location: The driver is a moving entity, so the driver’s location should be automatically updated after regular intervals.
-
Find nearby drivers: The system should find and show the nearby available drivers to the rider.
-
Request a ride: Riders should be able to request a ride, upon which the nearest driver will be notified about riders’ requests.
-
Manage payments: At the start of the trip, the system will initiate the payment process and manages the payments.
-
Show driver estimated time of arrival (ETA): The rider will be able to see the estimated time of arrival of the driver.
-
Confirm pickup: Drivers should be able to confirm that they have picked up the rider.
-
Show trip updates: Once a driver and a rider accept a ride, they should be able to constantly see trip updates like ETA and current location until the trip finishes.
-
End the trip: The driver marks the journey complete to become available for the next ride upon reaching the destination.
Food for thought!
What if two drivers have the same distance from the rider? How will we select the driver whom we will send the request?
Non-functional requirements
Following are the non-functional requirements that we will focus on while designing Uber:
-
Availability: The system should be highly available. The downtime of even a fraction of a second can result in a trip failure, the driver unable to locate the rider, or the rider unable to contact the driver.
-
Scalability: The system should be scalable to handle an ever-increasing number of drivers and riders with time.
-
Reliability: The system should be able to provide fast and error-free services. Ride requests and location updates should go off smoothly.
-
Consistency: The system should be strongly consistent. The drivers and riders in an area should have a consistent view of the system.
-
Fraud detection: The system should be able to detect any fraudulent activity related to payment.
Capacity estimations
Now let’s estimate the resource for our design. Let’s assume it has around 500M users/riders and about 5M drivers. Let’s assume the following numbers for our estimates.
- We have 20M daily active riders and 3M daily active drivers.
- We have 20M daily trips.
- All active drivers send a notification of their current location every 4 seconds.
Storage requirements
Let’s estimate the storage need for our system.
Rider’s metadata
Let’s assume we need around 1000 Bytes to store the rider’s information including ID, Name, Email, etc. when the users (riders) register in our application. To store the 500 Million riders that we assumed earlier, we will require 500 GB.
...
Create a free account to access the full course.
By signing up, you agree to Educative's Terms of Service and Privacy Policy