Design Uber

Overview

Uber is an application that provides ride-hailing services to its users. Anyone who needs a ride can register and book a vehicle to travel from source to destination. Anyone who has a vehicle can register as a driver and take riders to their destination. Drivers and riders can communicate through the Uber app on their smartphones.

Requirements

Let’s start with the requirements for designing a system like Uber.

Functional requirements

The functional requirements of our system are as follows:

• Update driver location: The driver is a moving entity, so the driver’s location should be automatically updated at regular intervals.

• Find nearby drivers: The system should find and show the nearby available drivers to the rider.

• Request a ride: A rider should be able to request a ride, after which the nearest driver should be notified about the rider’s requests.

• Manage payments: At the start of the trip, the system must initiate the payment process and manage the payments.

• Show driver estimated time of arrival (ETA): The rider should 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 upon reaching the destination, and they then become available for the next ride.

Non-functional requirements

The non-functional requirements of our system are as follows:

• Availability: The system should be highly available. The downtime of even a fraction of a second can result in a trip failure, in the driver being unable to locate the rider, or in the rider being 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 provide fast and error-free services. Ride requests and location updates should happen smoothly.

• Consistency: The system must be strongly consistent. The drivers and riders in an area should have a consistent view of the system.

• Fraud detection: The system should have the ability to detect any fraudulent activity related to payment.

Resource estimation

Now, let’s estimate the resources for our design. Let’s assume it has around 500 million riders and about five million drivers. We’ll assume the following numbers for our estimates:

• We have 20 million daily active riders and three million daily active drivers.
• We have 20 million daily trips.
• All active drivers send a notification of their current location every four seconds.

Storage estimation

Let’s estimate the storage required for our system:

• We assume we need around 1,000 Bytes to store each rider’s and driver’s information, respectively.

• We’ll need around 500 MB to store 500,000 new riders registered daily.

• We’ll need around 100 MB to store 100,000 new drivers registered daily.

• We need around 36 Bytes to store the driver’s location updates.

• We need around 100 Bytes to store single trip information.

So we need a total of $508 GB$ of storage approximately.

Bandwidth estimation

We’ll only consider drivers’ location updates and trip data for bandwidth calculation since other factors don’t require significant bandwidth. We have 20 million daily rides, which means we have approximately 232 trips per second.

$\frac{20000000}{86400} \approx 232\ trips\ per\ second$ ...