Location & realtime: free-recall review
Free-recall prompts across the location-and-realtime cases. Answer each from memory first — the index choice, the boundary fix, the fan-out layer, the routing preprocessing, the rank structure — then reveal the model answer and compare.
Retrieval beats re-reading. For each prompt, reconstruct a full answer from memory — including the mechanism, not just the name — before opening the model answer. The effort of rebuilding the spatial index, the region fan-out, and the sorted set is what makes them stick.
Reconstruct each case from memory without looking back: how you index space and dodge the boundary trap, why nearby-friends is write-heavy and how region pub/sub bounds the fan-out, why plain Dijkstra fails and what fixes it, and the structure that makes update, top-k, and rank cheap at once.
- 01Compare geohash, quadtree, and S2/H3, and explain the cell-boundary problem and its fix.
- 02Why is nearby-friends write-heavy, and how do WebSockets and region pub/sub make it work?
- 03Why does plain Dijkstra fail for Maps routing, and how do contraction hierarchies and live traffic fit together?
- 04Why is a sorted set the right structure for a leaderboard, and how do top-k, my-rank, ties, and sharding work?
- 05What single insight links all four cases, and where does each diverge?
If you could rebuild each answer from memory, you hold the unit’s spine. Proximity indexes space (geohash/quadtree/S2-H3) and queries a cell plus its neighbors as a coarse filter, ranking survivors by exact distance and caching per cell. Nearby-friends inverts it into a write firehose of ephemeral pings, pushed over WebSockets from a TTL store and routed by region pub/sub with the friend-and-range filter at the subscriber edge. Maps is dominated by precomputation — a tile pyramid on a CDN and routing via contraction hierarchies — with live traffic kept as a separate weight overlay so it never forces a re-contraction. The leaderboard uses a sorted set to make update, top-k, and rank-of-one all O(log n), where SQL makes rank an O(n) count, and shards by score range with global rank from per-shard counters. The unifying idea: each design follows the access pattern and turns “compare against everything” into “touch only a sliver”.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.