Uber-Style Driver Location

In one line

Driver location is a high-write, short-lived dataset: GEO sets per geographic cell for search, TTL-based freshness tracking, a lock or atomic claim for assignment, and regional sharding. It needs no durability; it regenerates every few seconds.

0/7 · 0%

Think of it like this

A taxi dispatcher's wall map with magnetic pins. Drivers radio their position every few seconds and the pins move; a pin that hasn't moved in a minute is removed; when a customer calls, the dispatcher looks only at the pins near them.

Key ideas

01
Writes: every driver every ~4 s → hundreds of thousands of GEOADDs per second globally. Shard by city and cell so no key or shard is overwhelmed; pipeline updates in the location service.
02
Reads: GEOSEARCH in the rider's cell (and neighbours), COUNT with a small radius first, expand if needed; rank candidates by ETA from a routing service.
03
Freshness: ZADD seen:{cell} <ts> driver alongside the geo set; prune entries older than 30 s every few seconds; ignore stale ones at query time.
04
Assignment: when offering a ride to a driver, SET offer:driver:{id} rideId NX PX 15000 so a driver can't receive two offers at once; on acceptance, remove them from the available set.
05
Regional isolation: each region runs its own Redis cluster; no cross-region traffic on the hot path.

Code & diagrams

location-update.lualua

Atomic cell move + freshness update. Keys for one city share a hash tag so they sit in one slot; for very large cities, tag per cell instead and move across cells from the app.

-- KEYS[1] = old cell geo key, KEYS[2] = new cell geo key, KEYS[3] = new cell seen zset
-- ARGV: lon, lat, driverId, now
if KEYS[1] ~= KEYS[2] then
  redis.call('ZREM', KEYS[1], ARGV[3])
end
redis.call('GEOADD', KEYS[2], ARGV[1], ARGV[2], ARGV[3])
redis.call('ZADD', KEYS[3], ARGV[4], ARGV[3])
return 1

Interview problem

The problem

Driver location service

Design the driver location system: 3M drivers online at peak worldwide, updates every 4 s, riders request nearby drivers, stale drivers must not be matched, and a driver must never get two ride offers simultaneously.

Explain it without notes

Why doesn't driver location need Redis persistence?

Practice

Estimate memory for 3M drivers in GEO sets plus seen sets.

Trade-offs

↔
Smaller cells spread load and reduce search cost, at the price of more multi-cell queries near borders.

Done when you can

I can design a high-write geo system with freshness, exclusivity and regional sharding.

Command Palette