Design Uber
What is Uber?
Uber is a ride-hailing platform that connects passengers with drivers through a mobile or web application. Users can request a ride, get matched with a nearby driver, track the ride in real time, and pay seamlessly through the app.
Drivers, in turn, can accept ride requests, navigate to pickup locations, and receive payments.
In this chapter, we will explore the high-level design of a ride-hailing platform like Uber.
Let’s start by clarifying the requirements.
1. Requirement Gathering
Before diving into the design, lets outline the functional and non-functional requirements.
Functional Requirements:
- Ride requests: Riders should be able to input their pickup and destination locations and request a ride.
- ETA/Fare Estimation: The system should provide an estimated time of arrival (ETA) and estimated fare to riders before they confirm the booking.
- Driver-rider matching: The system should match riders with available drivers who are in close proximity.
- Accept/Decline: Drivers should be able to accept or decline incoming ride requests.
- Driver tracking: Once a rider is matched with a driver, the rider should be able to track the driver’s location and view the estimated time of arrival (ETA).
- Ratings: Both riders and drivers should have the ability to rate each other after a ride is completed.
- Payments: The user should be able to complete the payment after the ride is completed.
Non-Functional Requirements:
- Low latency: The system should provide real-time location updates and fast driver-rider matching.
- High availability: The system should be up 24/7 with minimal downtime.
- Scalability: The system must handle peak loads (e.g., New Year’s Eve, sporting events).
2. Capacity Estimation
Assumptions
- Total Users: 50 million riders, 5 million drivers
- Daily Active Users (DAU): 10 million riders, 1 million drivers
- Peak concurrent users: 1 million riders, ~100,000 drivers (assuming 10% of DAUs are active at peak hours)
- Average Daily Ride Requests: 10 million globally
- Peak rides per second (RPS): ~5,000
Location Updates
- A driver sends a location update every 3 seconds while active.
- Assuming 100,000 active drivers at peak time:
- Location updates per second: 100,000 / 3 ≈ 33,333 updates/sec
Data Storage Estimation
User & Driver Profiles
- Rider profile: ~2 KB per user (name, email, phone, payment method, preferences)
- Driver profile: ~5 KB per driver (vehicle details, license, payment details, ratings)
- Total storage for 50M users: (50M × 2 KB) + (5M × 5 KB) = (100 + 25) GB = 125 GB
Ride Data
Each ride stores:
- Ride ID (UUID) → 16 bytes
- Rider ID, Driver ID → 8 bytes each
- Start & end location (lat/lon) → 16 bytes
- Fare, pickup/dropoff time → 24 bytes
- Status → 8 bytes
Total ride entry size: ~80 bytes
- Total daily rides: 10M
- Storage per day: 10M × 80 Bytes = 800 MB
- Storage per year (365 days): ~300 GB
Network Bandwidth Estimation
Each API call (ride request, driver update, fare estimation, etc.) contributes to network usage.
- Ride requests per second: ~5,000 RPS
- Driver location updates per second: ~33,333 RPS
- Total peak API requests: ~40,000 RPS
Assuming an average API payload size of 5 KB, network bandwidth usage at peak:
- 40,000 RPS × 5 KB = 200 MB/sec