Section 12: The Doors You Left Unlocked - Follow-up Feature Evolution

Executive Summary: This section is the roadmap conversation — the interviewer stops attacking the design and starts extending it. We price five plausible follow-ups against the day-one system: nearby strangers (where the geospatial index you spent Section 7 rejecting finally becomes the right answer), live trails, ETA sharing, geofenced places, and the analytics lane. Each lands on a flip trigger declared in advance, and none requires an architectural apology. The reusable lesson: a design that keeps its hot path small and refuses to hoard sensitive data buys cheap extensions for years.

The interviewer's tone changes. For twenty minutes they have been trying to break your system; now they lean back and say, "Product loves this. Here's the roadmap for next quarter." This is still an interview question. Extension requests probe something the deep dives cannot: whether your design was reasoned or merely defended. A design reasoned from first principles has already named the exact conditions under which each of its choices should be abandoned — so when product arrives with those conditions written on a slide, you get to say the most convincing sentence available in the room: "I was expecting that one."

Here is the whole roadmap, priced:

Four of those five rows were written months before the roadmap existed. That is what a decisions ledger with flip triggers is for.

The Nearby Strangers Door

Product wants discovery: people at this festival, people in this neighbourhood, dating-style "who is around right now". And now — only now — the global geospatial index is the right answer.

Go back to Section 7 and read the rejected alternative again. The geohash index over all ten million active sharers, the precision-5 cells of roughly five kilometres on a side, the multi-get across a covering set of cells, the exact haversine filter after the cell read. None of that analysis was wasted and none of it was wrong; it was the right answer to a different question, and the question just arrived. The search set for strangers genuinely is "everyone near me" — there is no four-hundred-ID friend list to use as an index, so there is nothing left to do but index geography.

One piece of the geometry is worth restating carefully, because the shortcut version of it is the most common whiteboard error in this whole family of problems. A three-by-three block of precision-5 cells spans about 14.7 kilometres edge to edge, and it is tempting to read that as "covers everything within seven kilometres". It does not. Your query point sits somewhere arbitrary inside its own centre cell — possibly hard against an edge — so a fixed three-by-three guarantees only one cell width in the worst direction: roughly 4.9 kilometres at the equator, and about 3.9 kilometres at San Francisco's latitude, because cell width scales with the cosine of latitude. Both numbers are less than the five-kilometre radius, so a fixed 3×3 silently misses friends. The fix is not a bigger constant; it is to compute the covering cell set from the query's bounding box — centre ± radius, converted to a cell range — which yields three by three in some places and more in others, and degrades gracefully as you move toward the poles or widen the radius.

Key Insight: The strongest signal in Section 7 was not rejecting the index — it was rejecting it with a condition attached. A candidate who says "a geospatial index is wrong here" is guessing. A candidate who says "a geospatial index is wrong here, and it becomes right the moment the search set stops being a friend list" has understood the problem well enough to predict their own reversal.

The build is a separate service, geo-partitioned, with its own cells, write path and capacity. It does not repartition the location cache — that was the explicit flip note on partitioning by user ID, because stadium-shaped hot spots are survivable in a service whose whole purpose is geography and were never survivable in the fan-out path. The friends path keeps user-ID partitioning, keeps its roughly 1.3 million messages per second of filtered fan-out, and does not notice the new feature exists.

The rejected alternative to that is tempting and must be named: make the geo index the one true location store and serve friends from it too. Refuse. You would reintroduce the hot cell on the write path and hand the strangers service — a surface with no mutual-friend gate — read access to the full-precision location of every user on the platform. Two stores, two trust levels, one coarsened feed from the live tier into the index. The duplication is the control.

Quick check before moving on: