Design the driver-matching service for a ride-hailing app. Tens of thousands of drivers per city each report their location every four seconds, and a rider request must be matched in under a second. Walk me through your design.

1. Reject the naive approach: computing distance to every active driver on every request is O(drivers) per request and will not hold. 2. Index space, not drivers: partition the map into a fixed cell grid (H3 hexagons or S2 cells) and key active drivers by cell id. 3. Justify hexagons over a square grid: uniform edge adjacency means all six neighbours are equidistant, so 'nearby' does not depend on direction, and there are no diagonal-vs-orthogonal distance artefacts. 4. Scope the candidate search to the rider's cell plus its ring of neighbours, expanding rings outward only if the candidate set is too small. 5. Separate the location-write path from the match-read path: high-frequency pings go to an in-memory store keyed by cell, not to the primary database. 6. Rank candidates by estimated time of arrival over the road network, not straight-line distance, because a driver across a river is close on the map and far in practice. 7. Batch matching over a short window (a second or two) instead of matching greedily per rider, so global assignment quality improves. 8. Handle cell-boundary and hot-cell cases: dense downtown cells need finer resolution, sparse suburbs need coarser.