Design Uber
Real-time Geospatial ridesharing system with matching, location updates, and ETA routing.
1. System Requirements
- Passengers request a ride, specifying pickup and destination coordinates.
- Drivers report their location updates every 4 seconds to the tracking system.
- Locate and match near drivers with passengers in real-time.
- Calculate routes, ETA, and show live trip updates.
- High availability (matching loop must never stop operating).
- Extremely low latency driver lookup (< 1s match latency).
- Strong consistency for trip state transactions (no double matching).
2. Scale & Resource Estimates
Throughput: 50 Million Daily Active Users, 1 Million Active Drivers. 1M drivers updates location every 4s = 250,000 location updates/sec writes. 100,000 ride requests/day = ~1.15 requests/sec reads.
Storage & RAM: Location updates: 250,000 * 24 bytes (driverId + lat + lon) = 6 MB/sec. Purged dynamically; persistent SQL data grows at ~2 GB/year.
3. System API Endpoints
// 1. Send active geospatial coordinate updates
POST /api/v1/driver/location
Request: { driver_id: "drv-9304", latitude: 40.7128, longitude: -74.0060 }
Response: { status: "success" }
// 2. Request active booking matching
POST /api/v1/ride/request
Request: { rider_id: "usr-4412", pickup: [40.7128, -74.0060], drop: [40.7580, -73.9855] }
Response: { trip_id: "trp-8812", status: "matching" }4. Database Schema Design
Table: drivers_location (Redis Geospatial Cache)
- driver_id (Key)
- geo_coordinates (Index: GEOADD tile indices)
Table: trips (PostgreSQL - sharded by rider_id)
- trip_id (UUID - Primary Key)
- rider_id (UUID - Sharding Key)
- driver_id (UUID - Foreign Key)
- status (ENUM: matching, active, completed)
- route_data (JSONB)5. Interactive High-Level Architecture
6. Scalability Deep Dive & Bottlenecks
Uses Geospatial sharding. The globe is divided into grid cells (e.g. Google S2 geometry library or Uber H3 hexagonal tiles). Location updates are written to Redis keys mapped directly to cell IDs. Matcher queries adjacent cells, bypassing scans of the entire world catalog. OSRM (Open Source Routing Machine) calculates exact routing and traffic-aware ETAs asynchronously.
7. Production Scaling Strategies
H3 Hex Partitioning: Shard driver locations by H3 cell resolution 7 (~5 km² per hex). Each Redis node handles ~100K cells. Hot-spot cities (Manhattan, Mumbai) get finer resolution 9 cells (~0.1 km²) to distribute load evenly.
Matching Service Scaling: Run matchers per-city as independent microservices. Each matcher queries only its city's geo-shards. At 250K location writes/sec, partition by city → district → zone for sub-100ms match latency.
Connection Scaling: 1M active drivers × persistent WebSocket = 1M TCP connections. Use 200 WebSocket gateway nodes (5K connections each) behind an L4 load balancer. Sticky sessions via consistent hashing on driver_id.
Surge Pricing Compute: Aggregate demand/supply ratio per H3 cell using Apache Flink sliding windows (2-min). Publish surge multipliers to Redis; drivers and riders read from edge cache. Decoupled from the matching hot path.
Trip DB Sharding: Shard PostgreSQL trips table by rider_id (hash). At 10× scale (10M daily trips), each of 16 shards handles ~625K writes/day. Use Citus for distributed joins on trip analytics.
Failure Handling: If a geo-shard Redis node fails, the consistent hash ring redistributes cells to surviving nodes in <5s. Drivers on the failed shard re-register on heartbeat. Trip state is persisted in PostgreSQL — no data loss on cache failure.
8. Runnable Production Starter Code
Scaffold