18.4 How do you update moving drivers?

On the map: Riders don't sit still. Every few seconds each one calls in: "I'm here now." If the map desk rewrote the whole index page for every call, it would never keep up. So it just moves the rider's pin, and only moves them to a different square's list when they cross a line.

In the system: The problem is write volume. With 10,000 riders pinging every 4 seconds, that's 2,500 location writes a second, all day, and most of them are only a few metres from the last one.

Figure: keep only the latest position in a fast in-memory index; send history elsewhere in batches.

How systems handle it:

• Keep the latest position in memory, not in the main database. A Redis GEO set or an in-memory quadtree or cell map holds "where is each rider right now". Only the latest point matters for matching.
• Most pings don't change cell. Update the rider's position in place, and move them between cells only when the cell changes. In the chapter's code, a rider moving at about 20 km/h for an hour sends 900 pings but changes 6-character cell only 33 times.
• Expire stale riders. If a rider's app hasn't pinged for, say, 30 seconds, they shouldn't be offered orders. Store a timestamp or a TTL and skip or remove old entries.
• Send history elsewhere. Trip history, analytics and ETA training data go to a log or queue (Chapter 22) and are written in batches, not on the hot path.
• Reduce pings when you can. Ping less often when a rider is stationary or off shift; the app can decide.

Memory code: "Keep only where they are now, and move them only when they cross a line."

---