Design Uber / Ride-Sharing
Full system design for Uber: geospatial indexing with S2 cells and QuadTree, real-time driver location updates via Kafka, driver-rider matching algorithm, surge pricing system, trip state machine, and GPS data streaming at scale.
Full system design for Uber: geospatial indexing with S2 cells and QuadTree, real-time driver location updates via Kafka, driver-rider matching algorithm, surge pricing system, trip state machine, and GPS data streaming at scale. This hands-on tutorial focuses on practical implementation of design uber / ride-sharing concepts.
Design Uber / Ride-Sharing
Uber's core challenge is geospatial real-time matching: matching millions of riders to drivers, knowing where every driver is at every moment, and dynamically pricing based on supply and demand — all in real-time across hundreds of cities simultaneously.
[!IMPORTANT] Geospatial systems require specialized data structures. You cannot use a SQL
WHERE latitude BETWEEN X AND Y AND longitude BETWEEN A AND Bquery at Uber scale — it requires full table scans. You must know at least one geospatial indexing approach: Geohash, QuadTree, or S2 cells.
Scale
- 5M drivers actively on-platform globally
- 1M+ concurrent rides
- Driver location updates every 4 seconds
- Rider request → matched driver in < 1 second
- Surge pricing recalculated every 1-2 minutes per zone
Geospatial Indexing
Real-Time Driver Location Updates
Surge Pricing Architecture
Quiz
Quiz
Question 1 of 25 million drivers update their GPS location every 4 seconds = 1.25M writes/second. Why can't this go directly to a PostgreSQL database?
Geospatial Indexing Comparison
| Method | Storage | Range Query | Nearby Search | Used By |
|---|---|---|---|---|
| Geohash | String | Good | O(8 cells) | Uber (legacy), Redis |
| S2 Cells | 64-bit int | Excellent | O(covering cells) | Uber H3, Google Maps |
| PostGIS | Geometry type | Excellent | O(log N) via R-tree | PostgreSQL apps |
| Quad Tree | Tree structure | Good | O(log N) | Game maps, small datasets |
Official Resources
- Uber Engineering Blog — Geospatial Index H3
- Uber Engineering — Real-time Marketplace
- Geohash Algorithm Explained
- Google S2 Geometry Library
Key Takeaways
✅ Geohash/S2 cells reduce geospatial search from O(N) (all drivers) to O(K) (drivers in nearby cells).
✅ Driver location: Redis for current location (fast reads), Kafka for history stream (analytics/ETA).
✅ Matching: Find nearby drivers → estimate ETA → assign best match → lock driver (atomic Redis SET NX).
✅ Surge pricing: Periodic batch job computes supply/demand ratio per zone → stores in Redis for real-time pricing.
✅ Trip state machine: Requested → Accepted → Arriving → InProgress → Completed (each state persisted in DB).
What's Next?
Uber is local and real-time. Netflix serves the same content globally at massive scale.
Next: Design Netflix / Recommendation Engine — Global CDN strategy, Open Connect, A/B testing, and collaborative filtering.