Section 1: Everyone Is Moving at Once - Problem Understanding & Clarifications

Executive Summary: This section covers the opening minutes of a Nearby Friends interview, where the problem most resembles a question it is not. We decompose the prompt across four dimensions (what, who, why, how), walk the clarifying exchange in which each answer eliminates a whole class of design, and name the two failure archetypes this question exists to catch. The pivotal realisation arrives here, before a single box is drawn: the search set is not "everyone near me", it is "my friends" — a list of roughly four hundred IDs. The friend list is the index, and everything in the next twelve sections follows from noticing it.

The interviewer doesn't warm up. One prompt, delivered flat:

"Design Nearby Friends. When a user opens the app, they should see which of their friends are currently near them — within a few kilometres — and get notified when a friend shows up nearby. Everyone is moving all the time."

You can feel the room's instinct pulling in one direction. Nearby. Kilometres. Somewhere in your training data is a diagram with a quadtree in it, and the temptation is to start drawing: index every active user by location, run a radius query when the app opens, intersect the results with the friend list, ship it. That instinct is the trap, and it is the whole reason this question is asked. It rewards pattern-matching on the shape of a prompt rather than reading what it says, and candidates who fall for it lose the interview in the first five minutes while sounding fluent the entire time.

Two archetypes fail here, and they fail in opposite directions.

The Index Reflex reaches straight for a geohash or quadtree index over all ten million active sharers, queries a radius on every app open, then throws away the strangers. It can even be made to notify on arrival — query the index as each location is written and intersect the candidates with the friend list — but that is where the costing collapses: thousands of candidate rows read per update, against the few dozen keyed cache reads the friend list would need, and every one of those reads touching the rows of people who are not party to the question.

The Realtime Maximalist hears "everyone is moving" and reaches for Kafka, Flink, exactly-once delivery and sub-second streaming, spending the entire latency and complexity budget on durability guarantees for data with a thirty-second shelf life and a freshness need measured in seconds.

Key Insight: Both archetypes are competent engineers answering the wrong question. The Index Reflex solves proximity search; the Realtime Maximalist solves event-stream durability. The scored skill in the first ten minutes is not recalling machinery — it is reading the problem precisely enough to notice which machinery is beside the point.

Why This Is Not the Proximity Problem

Say the contrast out loud, because it is the highest-value sentence available to you this early.

In the Proximity Service module — Yelp-style "restaurants near me" — the data is static: a restaurant sits at a coordinate for years. Reads dominate writes by orders of magnitude, so you build a geospatial index once and spend your effort on query efficiency. The search set is "every entity in this region", genuinely unbounded and genuinely in need of an index.

Here, every one of the three properties inverts. Every user is simultaneously a write and a reader, moving continuously. The data is ephemeral — a location is worthless within a minute, which means the storage question nearly evaporates. And the search set is tiny and pre-declared: not everyone within five kilometres, but the handful of your roughly four hundred friends who happen to be online. You already have that list. It is an adjacency list that fits in a few kilobytes of memory, and it does an index's job with a selectivity no spatial structure can match.

Critical Insight: This is a fan-out and messaging problem wearing a geospatial problem's clothing. Static data with heavy reads wants an index; moving writes with a tiny per-user search set want a publish-subscribe pipeline. Diagnose which one you are holding before you choose a data structure.

Quick check before moving on: