Designing a ride share service like Uber

Overview:

• Uber initially started as a taxi service. The initial design was focused on connecting cars with people.
• Most of the system architecture was redesigned as Uber expanded to provide other services such as UberPool, UberEats and so on.
• We can deep dive into many aspects of Uber architecture such as:
  • How Uber calculates accurate ETA?
  • How Uber calculates up to date pricing
  • How does Uber fight fraud
  • How Uber manages its API gateway
  • How Uber manages its datastores
  • How Uber matches rider to driver?
  • How Uber handles payment systems
  • How Uber manages, security, encryption, logging and metrics?
  • How is Uber Subscription defined?
  • and many more
• Most of the online videos focus only on the dispatch system (matching riders with drivers). Additional analysis is required to explore some of the above listed functionalities of Uber.

Uber Ride Sharing Feature: High Level flow:

• User engages Uber app and requests a ride
• Uber asks for location
• Uber finds nearby driver
• Uber app provides driver info. and ETA
• Once ride is over, user rates the driver/ride
• Payment automatically charged to credit card

The above functionalities of Uber App can be broken down into following services:

Stat:

• 3.5 million drivers worldwide, down from 5 million

Questions/Feedback:

• Do not see Database layer.
• Are we using cache?
• The interactions between microservices?
• How to find active drivers in the location where rider is?
• Mapping service for location service? How is it working?

Design Location Service for Uber:

Functional requirements:

• Drivers need to notify their current location to Uber every 3 seconds.
• Riders should be able to see all the nearby available drivers.
• Riders can request a ride; nearby drivers are notified that a customer is ready to be picked up.
• Once a driver and a customer accept a ride, they can constantly see each other’s current location until the trip finishes.

Non functional requirements:

• 300M riders and 1M drivers use the app.
• 1M active customers and 500k daily active drivers
• 1M daily rides.

Back of envelope calculation:

• This design requires frequent writes (to update driver location) and frequent reads (requests from riders)
• Geo data is maintained in Quadtree which is not suitable for frequent writes.
• Managing driver location in a hashtable and then flushing it to quadtree every minute may require the following:
  • Storing driver id, current latitude and longitude as well as old ones = 35 bytes.
  • 1M drivers = 35 * 1M = 35 MB
• QPS from drivers: 500K daily drivers = driver id + their current location = 20 bytes * 500K = 10 MB per 3 seconds