Uber & Ride Sharing (Maps/Geospatial)
Problem
Design a ride-sharing system like Uber — real-time driver tracking, matching, routing.
Why It Matters for You
⭐ Direct relevance: HCLTech geospatial engine — 250+ concurrent drivers, WebSocket tracking, sub-second latency. Use as your war story anchor.
Functional Requirements
- Rider requests a ride, gets matched to nearby driver
- Real-time location tracking (driver → server → rider)
- ETA calculation
- Surge pricing based on supply/demand
Non-Functional Requirements
- Low latency matching (< 1s)
- Location updates every 4–5 seconds (your real experience)
- High availability, consistent driver state
High-Level Design
Driver App → WebSocket Server → Location Store (Redis)
↓
Rider App → Matching Service → Geo Index (QuadTree/S2) → Driver List
↓
Route Service (maps API)
ETA + Pricing Service
Key Components
| Component | Your HCLTech Experience |
|---|---|
| WebSocket Server | Real-time driver state, 250+ concurrent |
| Geo Indexing | QuadTree / Geohash for spatial queries |
| Location Store | Redis with TTL per driver |
| Matching | Nearest N drivers + availability filter |
| ETA | Routing graph (Dijkstra / A*) |
Geo Indexing Deep Dive
- Geohash — encode lat/lng into a string prefix; nearby = shared prefix
- QuadTree — divide map into quadrants recursively; efficient range queries
- S2 Geometry — Google's library; Uber uses H3 (Uber's hexagonal grid)
Interview Angle (War Story)
"At HCLTech I built the real-time geospatial tracking engine — WebSockets for 250+ concurrent drivers, 5-second update intervals, sub-second latency. In a Uber-scale system, you'd replace direct WebSocket with a pub/sub layer, and the location store with a geospatially indexed Redis using Geohash."