Designing a Real-Time Ride-Sharing & Geolocation System (Uber / Lyft)
Architect a location-based dispatch and driver-matching engine using geospatial indexing (H3 / Uber Quadtrees), dynamic surge pricing algorithms, and distributed pub/sub routing.
Functional Requirements
- •Drivers broadcast GPS coordinates every 4 seconds
- •Riders search for nearby drivers within 5km
- •Real-time trip tracking with dynamic ETA routing
Non-Functional Requirements
- •Sub-second driver matching (<800ms)
- •High geospatial accuracy
- •Zero-downtime trip state persistence
Capacity & Scale Estimation
Core Architectural Components
1Location Ingestion Gateway
High-throughput gRPC service consuming driver GPS telemetry pings.
2Geospatial Index (H3 Hexagonal Grid)
In-memory distributed spatial grid partitioning the globe into discrete hexagonal cells for O(1) proximity lookups.
3Matching & Dispatch Engine
Calculates optimal driver pairing considering ETA, driver direction, and rating using Dijkstra / A* routing algorithms.
4Surge Pricing Engine
Real-time supply vs demand ratio calculator adjusting base fares dynamically per geographic polygon.
Architectural FAQs & Interview Deep Dives
Why is Uber H3 (Hexagonal) superior to Quadtrees or Geohashes for dispatch?
Hexagons have a constant distance between the center point and all 6 adjacent neighboring cells, eliminating the edge-distortion anomalies inherent in square or rectangular grids.
How is trip state preserved during network disconnects?
Trips use a Finite State Machine (FSM) backed by distributed event logs (Kafka) and persistent transactional storage (PostgreSQL) with optimistic locking.