High-Write Location Tracking

#Introduction

Every active driver sends a location update every few seconds.

At one million drivers, a 3-second heartbeat means more than 300,000 location writes per second before you store a single ride, message, or payment.

Driver location tracking is high-churn state. Treating it like normal durable profile data overloads the primary database and makes "nearest driver" stale.

This article supports Ride Matching and Dispatch and the Ride-Sharing Service solution. It is also a cousin of Presence and Ephemeral State: both deal with live state that should expire automatically.

#Location Update Path

A typical location update includes:

{
  "driverId": "drv_123",
  "lat": 40.741,
  "lng": -73.989,
  "heading": 210,
  "speedMps": 9.4,
  "sequence": 9921,
  "recordedAt": "2026-04-22T12:00:00Z"
}

The ingest service should validate sequence numbers, drop obviously impossible jumps, and write the latest state to a regional location store. Region choice matters; the update should land near the city that owns matching, as described in Regional Routing and Geo-Partitioning.

Do not append every ping to the primary transactional database. Durable trip history can be sampled or written asynchronously. Matching needs the latest useful location.

#TTL Location Index

Location availability expires naturally.

Store driver location in a cell-based index with TTL:

cell:dr5ru7 -> driver ids near that cell
driver:drv_123 -> latest location, state, expiry

When a driver moves cells, remove or expire the old cell membership and add the new one. If the driver disconnects, TTL expiration removes them from matching without a cleanup job.

Use regional routing. A driver in New York should update a New York regional cluster, not a distant global primary. The cell lookup itself is the moving-object version of Geospatial Indexing.

#Reducing Write Pressure

Not every GPS ping needs a full write.

Common tactics:

client-side throttling by distance and time
server-side coalescing
write only if the driver changed cell or ETA materially changed
keep latest location in memory or Redis with TTL
append sampled history asynchronously
publish location updates only to riders watching an active trip

For rider tracking, WebSockets can stream the assigned driver's location. For matching, the service usually needs a fresh index, not every historical coordinate. Historical trip analytics can be written later through Kafka, Flink, or another async pipeline.

#Common Interview Mistakes

Mistake 1: Writing every ping to SQL.

SQL can store trip history, but matching needs a high-write, low-latency latest-location index.

Mistake 2: Forgetting stale drivers.

If location state has no TTL, disconnected drivers stay matchable.

Mistake 3: Routing by user account instead of city.

Location writes should land near the geographic market where matching happens.

Mistake 4: Broadcasting every driver to every rider.

Only active trips and relevant map regions should receive live updates.

#Summary: What to Remember

Location tracking is ephemeral, high-write state.

Ingest updates regionally, validate sequence and freshness, keep latest location in a TTL-backed geo index, and write durable history asynchronously. Use throttling and coalescing so the system tracks useful movement instead of every raw GPS jitter.