EASYwalkthrough

Driver Location Service

7 of 8

3 related

500K active drivers each send a GPS update every 3 seconds. That is 167K writes per second of location data flowing into the system.

We chose Kafka as a buffer (not direct writes to Redis) because Kafka decouples the high-frequency write path from the geo index update path. Trade-off: we accepted 1-2 seconds of additional latency in exchange for zero data loss during downstream slowdowns.

“The constraint: writing 167K updates/sec directly to the geo index risks cascading failures if Redis is momentarily slow.”

The flow: driver app sends a PUT request with lat, lng, heading, speed, and timestamp. The request hits an API gateway that authenticates and rate-limits (20 updates per minute per driver).

Valid updates are published to a Kafka topic partitioned by driver_id. Kafka consumers read updates and perform two writes: (1) update the driver's position in the Redis geo index (H3 cell sorted set), and (2) append the update to Cassandra for historical analytics.

Each update is 33 bytes: driver_id (8B) + lat (8B) + lng (8B) + timestamp (8B) + status (1B). At 167K/sec, that is 5.5 MB/sec ingress, handled by a 3-broker Kafka cluster.

The entire active driver set fits in 16.5 MB of Redis memory (

500K \times 33\text{B}

). Implication: this is a compute problem, not a storage problem.

Why it matters in interviews

Interviewers want to hear the Kafka decoupling pattern: write-heavy ingestion buffered by a streaming layer before hitting the real-time index. What if the interviewer asks: 'Why not write directly to Redis and skip Kafka?' We answer: a 500ms Redis pause at 167K/sec means 83K updates queued in application memory. If the app server crashes during that pause, we lose 83K location updates. Kafka persists to disk first.

Related concepts

← PreviousETA Estimation Next →WebSocket Connection Management