Introduction to Uber [backup]

What is Uber?

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. Both drivers and riders can communicate through the Uber app on their smartphones.

There are many unanswered questions regarding Uber. How does it work? How do drivers connect with riders? etc. This chapter will design a system like Uber and find the answer to such questions. Prior to jumping into the design of Uber, let’s define the functional and non-functional requirements of the proposed system.

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.

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.

Server requirements

We need to handle concurrent requests coming from 20 Million daily active users. We established in the Back-of-the-envelope Calculations chapter that we will use the following formula to estimate a pragmatic number of servers:

$$\frac{Number\ of\ daily\ active\ users}{RPS\ of\ a\ server} = \frac{20 \times 10^6}{8000} = 2500$$ ...