750k/s
driver location updates at the evening peak
Design for 30 million trips a day: about 3 million drivers online at peak, each reporting every 4 seconds. That’s 700 writes per ride request.
Where do positions live?
Bad: A database table
Each move rewrites rows and indexes; dozens of shards fsync stale data.
Good: An in-memory index
Overwrite in RAM. Lose a shard; drivers refill it in 4 s.
Which drivers are near you? Ask 7 hexagons.
Each res-8 hexagon holds a set of available drivers. Read the pickup’s ring: 7 cells ≈ a 1.3 km radius, 19 ≈ 2.1 km.
Two riders, two drivers. Who gets which?
Nearest-first gives R1 the closest car and strands R2. Solving 2 seconds of requests together cuts total waiting from 12 to 7 minutes.
The car on your screen moves every 4 seconds, pushed over a stream. A flyover cuts your signal.
The trick
Resume from your last sequence number, but skip stale positions. Send only the newest.
Two dispatchers both see driver d_7 as available
Each reads “available”, then writes its own ride. Both win: d_7 gets two offers, and ride r_1 is silently lost.
The fix: the database decides, not the lock
- A Redis lease only filters out wasted offers
- Assign only if the driver’s version is still 41
- The loser updates no rows and offers its next driver
Remember
Two pipelines. Lossy locations live in memory, in H3 cells sharded on a ring. Rides are durable workflows, assigned by a conditional write. Rank by road ETA; push, never poll.