Read real geo-query code, a pub/sub routing config, a routing-engine setup, and Redis sorted-set commands, then do the reasoning: spot the single-cell bug, the broadcast blow-up, the re-contraction trap, and the O(n) rank query.
SDCSenior◷ 14 min
Level
FoundationsJuniorMiddleSenior
The bugs in these systems live in the code, not the prose: a query that reads one cell, a publish that goes to everyone, a routing setup that re-preprocesses on every traffic tick, a rank query that scans. Read each snippet, run it in your head, and pick the answer a senior engineer would commit to.
Practise the design-review loop: locate the access pattern in the code, match it to the right structure, and choose the change the architecture actually supports.
Snippet 1 — the proximity query
def nearby(lat, lng, radius_m): cell = h3.geo_to_h3(lat, lng, res=9) # the user's own cell candidates = store.get_by_cell(cell) # only this one cell return [p for p in candidates if haversine(lat, lng, p.lat, p.lng) <= radius_m]
Quiz
Completed
What's the bug in nearby(), and how do you fix it?
Heads-up A cell is a coarse bucket, not a circle — it contains places outside the radius and excludes ones just over its edge. You need BOTH the neighbor query (so nothing close is missed) and the exact-distance filter.
Heads-up Coarsening the cell crudely grabs far-away places and still misses the boundary case asymmetrically. The correct fix is to query neighbor cells (kRing) at a resolution matched to the radius, then filter by exact distance.
Heads-up The distance math is fine; the structural bug is reading a single cell. ORDER BY distance over all rows is the O(n) scan the cell index exists to avoid.
Snippet 2 — the location publisher
def on_ping(user_id, lat, lng): store.set(user_id, (lat, lng), ttl=30) for conn in all_connections: # every connected client conn.send({"user": user_id, "lat": lat, "lng": lng})
Quiz
Completed
At 2M pings/second this loop melts the cluster. What's the structural fix?
Heads-up A background thread still sends to every connection — the total work is the same quadratic blow-up, just off the ingest thread. The fix is to NOT send to everyone: route by region channel and filter at the edge.
Heads-up Batching reduces syscalls but still delivers each ping to every connection — the recipient set is the problem, not the flush cadence. Publish per region cell so only nearby subscribers receive it.
Heads-up TTL governs expiry, not who receives a ping. The melt is the all-connections fan-out; fix it with region-keyed pub/sub plus an edge friendship/range filter.
Snippet 3 — the routing engine setup
def update_traffic(edge_id, new_travel_time): graph.set_weight(edge_id, new_travel_time) graph.build_contraction_hierarchy() # runs on every traffic update return graph# called ~thousands of times per second from the probe stream
Quiz
Completed
Why is this catastrophic, and what's the right architecture?
Heads-up A cache doesn't help when the weights change every call — each update invalidates the cached hierarchy. You must decouple structure from weights so live traffic overlays without rebuilding.
Heads-up That sacrifices the speed you need at planetary QPS. Keep the preprocessing but partition it by rate of change: structure preprocessed rarely, weights overlaid live.
Heads-up No machine contracts a continental graph in the milliseconds between traffic ticks. The architectural fix is separating structure from weights, not faster hardware.
Snippet 4 — the rank query
-- a player's rank on the leaderboardSELECT COUNT(*) + 1 AS rankFROM scoresWHERE score > (SELECT score FROM scores WHERE player_id = :id);-- called per player, millions polling their own rank
Quiz
Completed
Why does this query scale badly, and what replaces it?
Heads-up An index helps locate rows but COUNT(*) over all higher scores is still O(n) work per query. A ZSET's ZREVRANK is genuinely O(log n) — it sums precomputed spans instead of counting rows.
Heads-up A nightly view makes rank stale (scores change live) and is O(n) to refresh for all players, most never viewed. ZREVRANK computes any rank fresh in O(log n) on read.
Heads-up Updating a stored rank on a score change can shift the rank of everyone below — O(n) per write. A sorted set keeps rank implicit in its structure, so reads are O(log n) and writes are O(log n).
Recall before you leave
01
Two code smells that signal a proximity or fan-out bug, and their fixes?
02
Why is re-running contraction on every traffic update wrong, and why is a SQL rank query slow — what replaces each?
Recap
Every failure in this unit is visible in the code and structural, not a tuning detail. A proximity query that reads one cell misses the place across the boundary — query the neighbor ring and filter by exact distance. A location handler that sends each ping to all connections is a quadratic broadcast — publish by region cell and filter at the subscriber edge. A routing engine that rebuilds the contraction hierarchy on every traffic tick is impossible at continental scale — separate structure from weights so traffic overlays live. And a SQL rank query (COUNT(*) WHERE score > mine) is an O(n) scan per poller — replace it with a sorted set whose ZREVRANK is O(log n). The senior habit is the same each time: read the access pattern off the code, then choose the data structure or routing that fits it — never the version that hides an O(n) or a re-computation on the hot path.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.