Location & realtime: build a live proximity + leaderboard service
Hands-on project: build a working find-nearby service over a spatial index (querying neighbor cells), add a realtime push channel for moving entities by region, and back a leaderboard with a sorted set — then prove rank and proximity correctness with a small test harness.
Reading that you should query neighbor cells and put rank in a sorted set is not the same as building a service that survives a moving load. Take the unit’s three primitives — a spatial index, a region push channel, and a sorted set — and assemble a small but real location-and-realtime service, then prove the two correctness properties most likely to bite you: that proximity finds the across-the-boundary neighbor, and that a player’s rank is right among millions.
This project makes the unit operational: you implement the coarse-then-fine proximity query, the region fan-out that avoids a broadcast, and the O(log n) rank engine, then write tests that catch the canonical bugs — the missed boundary neighbor and the wrong global rank.
Build a working location-and-realtime service with three parts — a find-nearby query over a spatial index, a realtime push channel for moving entities routed by region, and a sorted-set leaderboard — and prove with a test harness that proximity returns across-boundary neighbors and that ranks (including global rank under sharding) are correct.
- A find-nearby endpoint that, on randomized inputs including boundary-adjacent points, returns exactly the same set as a brute-force distance scan — demonstrating the neighbor-ring query fixes the cell-boundary problem.
- A measured cache hit-rate on the skewed read load, with a one-line note on why caching by cell pays off given the read-heavy, slow-changing place data.
- A working realtime demo where a moving entity's pings reach only subscribers of its current region cell (shown by a log or counter), with the subscription re-pointing on a boundary crossing and a non-friend never receiving a location.
- A leaderboard whose update, top-k, my-rank, and window operations all run without a full scan, with ties resolved deterministically by the composite score.
- A test proving global rank under score-range sharding equals the brute-force sorted rank for randomized scores, plus a short note on how per-shard counters make it O(shards) rather than a cross-shard scan.
- Add density adaptivity: switch a hot, overflowing cell to a finer resolution (or a quadtree subdivision) and show the candidate count per query drop, keeping dense-area latency bounded.
- Add a tiny routing component: build a small road graph, contract it into a hierarchy, and show that a bidirectional upward search returns the same shortest path as plain Dijkstra while expanding far fewer nodes.
- Add adaptive ping rates to the realtime channel (slower when an entity is stationary, faster when moving) and measure the write reduction versus a fixed interval at equal perceived freshness.
- Add time-windowed leaderboards (daily / weekly / all-time) as separate sorted sets and discuss how this both shrinks each board and spreads write load.
- 01What are the three primitives this project assembles, and what does each demonstrate?
- 02How do you prove the two correctness properties, and why those two?
- 03Why build all three together rather than in isolation?
This project turns the location-and-realtime unit into a working system built from three primitives. The proximity part implements coarse-then-fine search over a spatial index — fetch the cell plus its neighbor ring, filter by exact distance, and cache by cell on the read-heavy load — and is proven correct against a brute-force scan including boundary-adjacent points, the test that exposes the single-cell bug. The realtime part stores moving entities with a TTL keyed by region cell, publishes per-cell over a persistent connection, re-subscribes on boundary crossings, and enforces a friendship filter at the subscriber edge rather than broadcasting. The leaderboard part uses a sorted set for O(log n) update, top-k, my-rank, and window, with a composite-score tiebreaker, and shards by score range so global rank is in-shard rank plus higher-shard counts — proven against a brute-force sort. Building all three together makes the unifying lesson tangible: the same region-cell abstraction is a search index, a routing key, and a partition axis, and the right structure always follows the access pattern.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.