This article was written with the assistance of AI tooling for structure and syntax. The concepts, tradeoffs, and production context are based on my own engineering experience and research. #ABotWroteThis
You’re building the “find nearby drivers” feature for a ride-hailing app.
At peak, you have 500,000 active drivers updating their GPS location every 5 seconds. Riders query for drivers within 2km. At scale, you’re doing ~100,000 proximity queries per second.
Your naive implementation does this:
SELECT * FROM drivers
WHERE lat BETWEEN ? AND ?
AND lng BETWEEN ? AND ?
Enter fullscreen mode Exit fullscreen mode
It works fine at 1,000 drivers. At 500,000, it’s a full table scan on every query. Latency hits 800ms. Riders see a spinner. Drivers miss trips.
Your team proposes 4 approaches to fix this:
A) Geohash partitioning — Encode each driver’s location into a geohash string. Index by geohash prefix. Proximity queries become a string lookup on the index.
B) PostGIS with spatial indexes — Add a PostGIS extension to Postgres. Use a proper R-tree/GiST spatial index for bounding-box and radius queries.
C) Quadtree in memory — Keep all active driver positions in a quadtree data structure in a Redis-backed in-memory service. Decompose space recursively until each cell has ≤ N drivers.
D) H3 hexagonal grid (Uber’s system) — Divide the earth into hexagonal cells at multiple resolutions. Assign each driver to a cell. Queries check the target cell + 6 neighbors at the right resolution.
You need sub-50ms p99 latency, real-time updates, and it has to stay accurate at cell boundaries.
Pick one — A, B, C, or D — and tell me why. Full breakdown in the comments.
If your team has argued about spatial indexing before, share this. Worth the debate.
Drop your answer 👇
답글 남기기