A ride-hailing platform receives location updates from hundreds of thousands of active drivers every few seconds. Design the ingest and serving path.

What the interviewer is testing

Whether you separate the write path from the query path, and whether you recognise that not every update needs to be durable.

The two very different requirements

Ingest is enormous, continuous, and mostly disposable. Hundreds of thousands of drivers at one update every four seconds is on the order of a hundred thousand writes per second, and the value of an individual position decays to nothing within seconds.

Query is "which drivers are near this point, right now", answered in milliseconds, thousands of times per second.

Treating these as one problem — write every position to a durable store and query it — produces a system that is both expensive and slow.

The design

Current position in memory, keyed by spatial cell. The serving layer holds only the latest position per driver, indexed by a geospatial cell identifier so that "near this point" is a lookup of a small set of cells rather than a distance calculation over everyone. This is what H3 or similar hierarchical cell schemes are for, and the cell id doubles as a partition key so that a query touches few partitions.

Losing a position is acceptable. The next update arrives in seconds. That single realisation removes the durability requirement from the hot path and is what makes the design affordable.

A durable stream for everything else. Positions also go to a log for the uses that genuinely need history — trip reconstruction, ETA model training, supply analytics, fraud, dispute resolution — read asynchronously by consumers that do not sit in the request path.

Adaptive reporting rate at the client. A stationary driver reports less often than a moving one. This is the largest single volume reduction available and it happens before anything reaches the network.

What a strong answer adds

Hexagonal cells rather than square ones for the analytical uses, because a hexagon's six neighbours are all equidistant while a square has edge-neighbours and corner-neighbours at different distances — which distorts any smoothing, clustering or supply-demand gradient calculation.

And the partition-key consequence: sharding by cell gives locality, so spatial queries stay within few partitions. That is the property that makes real-time geospatial affordable at all.

Common weak answers

Writing every position to a relational database with a spatial index. Treating durability of individual positions as a requirement without questioning it.