Case Studies
Uber
Geospatial indexing for matching a rider to nearby available drivers, and the offer/timeout/reassign loop.
Matching a rider (or a delivery) to the nearest available driver out of a huge, constantly-moving pool — widely known in interview prep as "the Uber problem," and a good vehicle for testing geospatial indexing specifically, since "find nearby drivers" is a different problem from any lookup covered elsewhere in this track.
What this lesson covers
Index driver locations by geohash so nearby drivers share a prefix, then search the rider's cell and expand outward. Drivers push location updates; the offer goes to the top candidate under a Redis lock with a TTL and moves to the next driver on timeout.
- Millions of drivers report locations every few seconds; a match must find nearby available drivers without scanning them all.
- Location updates are write-heavy while match queries are comparatively rare, and the index has to be shaped for that imbalance.
- 'Find nearby drivers' is a geospatial problem unlike any lookup elsewhere in the track; naming a spatial index is the senior bar.
- Offering a ride is a loop: offer, short timeout, reassign; the lock around the offer is a trade-off to defend, not assert.
- Uneven driver density (downtown vs. suburb) changes cell size and query fan-out, and the offer TTL is itself a tuning lever.
Included in Plus and Pro
Continue reading “Uber”
The full lesson works the design through end to end — diagrams, trade-offs, and what interviewers expect at each level. About 19 minutes.
- Understanding the Problem
- Functional Requirements
- Non-Functional Requirements
- Capacity Estimation
- Core Entities
- API Interface
- High-Level Design
- Trade-offs
- Final Design
- Operations & Observability
- Level Expectations
- Follow-Up Questions
- Try It Yourself