Design interviews / Intermediate / 6 min
Design Uber: finding the nearest driver
Drivers report locations; riders need the closest one fast. Compare scanning every driver with searching geo cells, and see stale locations.
Start the simulation → Change the load, break a part, watch what happens. Free, no sign-up.
In short
- What it is
- Uber keeps every driver’s latest location in a geospatial index and, for each ride request, searches nearby cells for the closest free driver.
- Why it matters
- Millions of location updates and requests arrive every minute, and a rider expects a match in seconds.
- The trade-off
- Frequent location updates give accurate matches but cost writes; small cells mean fewer checks but more misses at cell edges.
- Say it in an interview
- "Drivers send GPS every few seconds to a location service holding an in-memory H3/geohash index (Redis GEO), matching searches k-rings around the rider, then ranks by ETA."
Check yourself
Why split the map into cells (geohash, H3) for matching?
Answer: Only drivers in the cells around the rider are checked, not every driver in the city. A geo index turns "nearest driver" into a lookup of a few cells, so cost stays small as the city grows.
Drivers send their location every 30 seconds instead of every 4. What goes wrong?
Answer: The server matches on old positions, so the chosen driver may have driven away. Staler locations mean worse matches; more frequent updates are accurate but multiply write load.
What is the risk of searching only the nearest rings of cells?
Answer: A slightly closer driver just outside the searched rings can be missed. Cell search is approximate; searching one extra ring after the first hit reduces misses at a small cost.