Location & realtime: multiple-choice review
Multiple-choice synthesis across the location-and-realtime cases: spatial indexing and the cell-boundary trap, write-heavy location fan-out, contraction hierarchies for routing, and the sorted set behind a leaderboard's rank query.
Six decisions that cut across the four cases. Each is a choice you make at a whiteboard — how to index space, where to run the fan-out, which algorithm survives a continental graph, what structure answers “my rank among millions” — not a definition to recite.
Confirm you can pick a spatial index for the access pattern, fix the cell-boundary trap, place location fan-out at the right layer, reject plain Dijkstra at continental scale, and choose the structure that makes rank-of-one cheap.
A find-nearby service queries only the user's own geohash cell and ranks the places in it. Users report a clearly close shop is sometimes missing. What's the fix?
A fixed-resolution square grid overflows in Times Square (one cell holds tens of thousands of places) while ocean cells are empty, and dense-query latency is terrible. What structural change helps most?
A nearby-friends system ingests 2M location pings/second. An engineer proposes, on each ping, loading the publisher's friends, fetching their locations, and pushing to the nearby ones. Why prefer region-keyed pub/sub?
A team builds continental routing with plain Dijkstra; it's correct but takes seconds per query, expanding millions of nodes. Which preprocessing makes queries touch only thousands of nodes while still returning the exact shortest path?
A leaderboard stores scores in a SQL table indexed on score. Top-10 is fast, but showing each of 12M players their own live rank crushes the database. What's the root cause and fix?
You shard a leaderboard by score range across nodes because one node can't hold it. How do you still answer a player's GLOBAL rank without a scan?
- 01Why must a proximity query fetch a cell's neighbors, not just the cell?
- 02Why is rank-of-one cheap in a ZSET but expensive in SQL?
The through-line of the unit is that the right design falls out of the access pattern. Proximity is read-heavy and slow-changing, so you build a spatial index and query a cell plus its neighbors as a coarse filter, ranking the survivors by exact distance; density skew is fixed by adaptive resolution (quadtree, S2/H3). Nearby-friends inverts this into a write firehose, so you push over WebSockets from an ephemeral TTL store and route by region pub/sub, running the friend-and-range filter at the subscriber edge rather than as a graph+geo join on ingest. Maps is dominated by precomputation: tiles on a CDN, and routing via contraction hierarchies so a query rides a few shortcuts instead of expanding millions of nodes, with live traffic kept as a separate weight overlay. The leaderboard needs update, top-k, and rank-of-one together, which a sorted set delivers in O(log n) where a SQL ORDER BY makes rank an O(n) count — and it shards by score range with global rank computed from per-shard counters.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.