Designing Uber/Lyft is one of the most popular tasks in System Design interviews. This is a real-time system with millions of simultaneous users, geolocation, matching algorithms and dynamic pricing.
Source
System Design Interview
Proximity Service and Location-based systems are discussed in detail in the book by Alex Xu.
Uber scale
Uber
Uber Engineering Blog
Technical articles on Uber scaling, architecture and infrastructure
1Functional Requirements
Rider Flow
- •Specify pickup and destination
- •See ETA and price before confirmation
- •Request a ride and get a driver
- •Track driver in real-time
- •Pay and leave a review
Driver Flow
- •Go online/offline
- •Receive travel requests
- •Accept or reject the request
- •Navigation to pickup and destination
- •Complete the trip and receive payment
2Non-functional requirements
Low Latency
Matching < 1 min. Location updates every 3-4 seconds.
High Availability
99.99% uptime. People depend on the service for transportation.
Scalability
Peak hours: 10x load. New Year, concerts, weather.
Load Estimation
3Real-time Location Tracking
Related topic
Geo indexing
Approaches to geosearch (Geohash, Quadtree, S2) are discussed in the Airbnb case.
⚠️ Main difficulty
1 million drivers send location every 3-4 seconds = ~300K writes/second. A specialized architecture is needed.
Driver Location Service
- •Receives location updates from drivers
- •Stores in in-memory store (Redis)
- •TTL 30 seconds - automatic offline
- •Publishes to Kafka for other services
Geo indexing
To quickly search for nearby drivers:
# Redis GEO commands
GEOADD drivers {lng} {lat} driver_123
GEORADIUS drivers {lng} {lat} 5 km
WITHDIST WITHCOORD COUNT 10
# Or Geohash approach
SET driver:123:location "9q8yy"
SMEMBERS geohash:9q8yy:driversWikipedia
Geohash
Algorithm for encoding coordinates into a string for spatial indexing
Location Service Architecture
- 1Driver app sends location via WebSocket or UDP
- 2Location Gateway accepts and batches updates
- 3Redis Cluster stores current location (geo index)
- 4Kafka stream for history and analytics
4Driver-Rider Matching
Matching Flow
- 1Rider requests a ride
Pickup location, destination, ride type (UberX, Black, Pool)
- 2Dispatch Service finds candidates
GEORADIUS in Redis, filtering by ride type and status
- 3Ranking candidates
ETA, driver rating, acceptance rate, direction of travel
- 4Sending a request to the best driver
Push notification with timeout 15-30 seconds
- 5Driver accepts or rejects
If rejected, next candidate
Single Dispatch
We send a request to one best driver:
- + Simple implementation
- + Valid for drivers
- - Slower on failures
Broadcast (Batch)
We send to several drivers, the first one wins:
- + Faster matching
- - Competition between drivers
- - More difficult fairness
Supply Positioning (Heat Maps)
Uber shows drivers areas with high demand to optimize distribution:
- •Demand prediction: ML model based on time, weather, events
- •Supply tracking: Current distribution of drivers by zones
- •Incentives: Bonuses for travel in certain zones
5ETA Calculation
Optimization
Caching ETA
ETAs for popular routes can be cached similar to a CDN.
ETA components
Pickup ETA
Time from the current driver position to the pickup point. Shows rider when prompted.
Trip ETA
Time from pickup to destination. Affects pricing.
Calculation factors
- Road graph
- Speed limits
- One way streets
- GPS data drivers
- Accidents, traffic accidents
- Traffic jams
- Day of the week
- Times of Day
- Seasonality
Routing Engine
Uber uses its own routing engine based on:
- •Contraction Hierarchies: Graph Preprocessing for Fast Queries
- •A* algorithm: For short distances taking into account traffic
- •ML corrections: Adjustment based on historical errors
6Dynamic (Surge) Pricing
Uber Engineering
H3: Hexagonal Hierarchical Index
Uber open-source library for geospatial indexing with hexagonal grid
Why Surge Pricing?
Demand Side
High price cuts off riders with low urgency, freeing up cars for those who really need it.
Supply Side
High price attracts more drivers to the area with high demand.
Surge Multiplier calculation
# Simplified formula
surge_multiplier = demand / supply
# Where:
# demand = ride_requests in the zone in the last N minutes
# supply = available_drivers in zone
# Example of zones (Geohash or H3 cells)
zone_9q8yy:
demand: 50 requests/5min
supply: 10 drivers
surge: 5.0x → cap at 3.0x
# Surge applied to base fare
final_price = base_fare * surge_multiplierSurge Zones
- •The city is divided into hexagonal cells (H3)
- •Each cell has its own surge multiplier
- •Update every 1-2 minutes
- •Smoothing between adjacent cells
Price Lock
- •Rider sees the price before confirmation
- •The price is fixed for 5-10 minutes
- •Surge protection
- •Quote ID for tracking
7Trip Lifecycle
Current step
1. Requested
Rider submits pickup, destination, and ride type. The system stores the quote and starts driver search.
- • Pickup/destination validation + serviceability zone check
- • Rate limits and anti-fraud checks
- • Quote ID and TTL for the fare offer
Next transition
2. Driver Assigned
If the current step completes successfully, the trip moves to the next lifecycle state.
Real-time Updates
Rider sees the driver in real-time via:
- •WebSocket: Persistent connection for updates
- •Push notifications: Status changes
- •Polling fallback: Every 5 seconds
Cancellation Handling
- •Rider cancellations before match: free
- •Rider cancels after 2 min: cancellation fee
- •Driver cancels: penalty to rating
- •Driver no-show: full refund + credits
8High-Level Architecture and standard scenarios
Architecture + Scenario Explorer
Real-time dispatch topology for ride-hailing systemsRequest and Dispatch Plane
ETA, Pricing and Settlement Plane
Sustainable ride-hailing design is built around separation of concerns: real-time dispatch path isolated from pricing/payment pathso that the peak in location updates does not break monetary transactions.
Data Stores
Driver locations, surge multipliers, session data
Users, trips, payments (transactional)
Location history, trip events (time-series)
9Key interview points
✓ Be sure to discuss
- •Location tracking: how to process 300K writes/sec
- •Geo-indexing: Geohash vs Quadtree vs H3
- •Matching: single dispatch vs broadcast
- •ETA: road network + real-time traffic
- •Surge: demand/supply balancing
💡 Additional themes
- •UberPool: group rides with routing optimization
- •Fraud detection: fake drivers, GPS spoofing
- •Safety features: trip sharing, emergency button
- •Scheduled rides: future demand prediction
- •Multi-modal: bikes, scooters, transit integration
Common interview mistakes
- ✗Store location in a regular SQL database (will not withstand the load)
- ✗Forget about scale: 300K location updates per second
- ✗Ignore real-time traffic in ETA calculations
- ✗Can't explain why surge pricing is needed