Design a Nearby Friends Location Service

This page is one interview loop in three rounds. All three rounds design the same system. Each round opens with the interviewer raising the scope, and the design from the round before has to evolve to meet it.

You can start at any round. Rounds 2 and 3 open with a "Where we left off" summary that catches you up.

Loop Opener: What Is a Nearby-Friends Feature?

A Room Where You Only See the Friends Who Walked In

Imagine a huge room with the whole world in it. You can't see strangers at all. But whenever one of your friends is within a few steps of you, they light up, and you can see where they stand and watch them move. They see you the same way. Nobody else sees anything.

That is a nearby-friends feature: Snap Map, Find My, and the old Facebook "Nearby Friends" all work like this. Each phone reports where it is. The service tells each person which of their friends are close right now, and keeps everyone else's location away from them.

A few words we'll use all page:

What Makes It Hard

• Everything moves. In the proximity loop, the places were static and only the searcher moved, so we could build an index once and read it forever. Here every "place" is a person, and every person moves all the time. There is nothing to precompute.
• Every update could go to hundreds of people. A user with 400 friends who sends an update every 30 seconds could produce 400 deliveries each time. Most of them are wasted: the friend is offline, or on another continent.
• Location is the most sensitive data a phone has. A trail of positions reveals where someone sleeps, works and worships. One leaked update to the wrong person can put someone in danger.
• Batteries. GPS and the phone's radio are among its most power-hungry parts. A feature that drains the battery gets turned off.

The Question the Whole Loop Answers

How do we tell each person which friends are near, right now, without sending every update to everyone or leaking where anyone is?

The answer grows every round:

• Round 1: keep only each person's latest location, in memory, and compute distances to their friends when they open the app.
• Round 2: push live updates over persistent connections, and prune the fan-out down to friends who are online and nearby. Enforce privacy modes on the server.
• Round 3: serve users from their home region wherever they travel, minimize what we keep, design against stalking, and spend the phone's battery only when someone is looking.

---

Round 1 · Mid-level · "Friends Nearby for a Campus App"

~35 min · SDE II (L5) · 1 region · 100K users sharing at peak · 3,333 updates/s peak · positions under 1 min old · 99.9%

R1.1 Establish Design Scope

The interviewer says: "A university app wants a 'friends nearby' tab. Students share their location with friends and see which friends are within 5 km. Design the backend." Before drawing anything, we ask.

Out of scope for this round: live map updates, fuzzy location, "a friend is within 1 km" alerts, and location history.

R1.2 Functional Requirements, Derived Step by Step

Not yet: live push, fuzzy mode, proximity alerts.

R1.3 Non-Functional Requirements: the Questions

We name each quality first; the numbers come in R1.7.

• Freshness. A friend's position on screen should be under a minute old. That bounds how often phones send and how often the list refreshes, together.
• Privacy. Only friends see you, only while sharing is on, and turning it off must take effect at once. We keep nothing we don't need.
• Battery. A phone that sends a GPS fix every 5 seconds all day is dead by dinner. The send rate is a product decision, not just a server one.
• Cost of frequent writes. Every sharing phone writes every 30 seconds, and we only ever read the latest value. Storing every write durably would be paying for data we throw away.

R1.4 The API

Send my location

httpCopy
PUT /v1/me/location HTTP/1.1
Host: api.campusfriends.example
Authorization: Bearer <access token>
Content-Type: application/json

{ "lat": 37.7793, "lon": -122.4193, "accuracy_m": 12, "measured_at": "2026-10-05T14:02:31Z" }

httpCopy
HTTP/1.1 200 OK
Content-Type: application/json

{ "stored": true, "next_update_s": 30 }

• measured_at is when the phone measured the position, not when the request arrived. A request that was delayed in a tunnel and arrives after a newer one must not overwrite it.
• next_update_s is the server's hint for when to send again (step 1.4). The server can slow every phone down without shipping a new app.

List nearby friends

httpCopy
GET /v1/me/nearby-friends HTTP/1.1
Authorization: Bearer <access token>

jsonCopy
{
  "friends": [
    { "user_id": 4411, "name": "Bob", "distance_m": 1418, "age_s": 12 },
    { "user_id": 5120, "name": "Carol", "distance_m": 2193, "age_s": 27 }
  ],
  "refresh_after_s": 20
}

Turn sharing on or off

httpCopy
PUT /v1/me/sharing HTTP/1.1
Authorization: Bearer <access token>
Content-Type: application/json

{ "enabled": false }

Status codes

Recap

• One latest position per user; a list of friends within 5 km, computed on request.
• 200 friends each, 100K sharing at peak.
• Sharing off must be immediate; positions under a minute old.

R1.5 Design Evolution: From a Ping Log to Live State

Each step is a problem, your turn to think, the answer, and what it costs us.

Step 1.0: The Baseline

A pings table in a relational database. Every update inserts a row. To list nearby friends, we look up the friend list, fetch each friend's newest row, and compute distances.

sqlCopy
CREATE TABLE pings (
    user_id     BIGINT      NOT NULL,
    measured_at TIMESTAMPTZ NOT NULL,
    lat         DOUBLE PRECISION NOT NULL,
    lon         DOUBLE PRECISION NOT NULL,
    accuracy_m  REAL,
    PRIMARY KEY (user_id, measured_at)
);

-- the newest row per friend, for one "open"
SELECT DISTINCT ON (user_id) user_id, lat, lon, measured_at
FROM pings
WHERE user_id = ANY(:friend_ids)
ORDER BY user_id, measured_at DESC;

It works on day one, and it's where every candidate should start. The trouble is what it keeps.

Step 1.1: The Database Fills With Pings We Never Read

Primitive: Distributed Cache Patterns and Eviction

Step 1.2: On Open, We Load 200 Friends' Locations

Step 1.3: Friends Who Stopped Sharing Still Appear

Step 1.4: Phones Drain Their Batteries Sending Every 5 Seconds

Round 1 Step Summary

R1.6 Architecture v1

Synthesizing vector architecture diagram...

Every request goes to a small stateless API. Positions, flags and cached friend lists live in Valkey; the durable facts (who is friends with whom, and the sharing switch) live in DynamoDB.

Key layout

The cluster uses the volatile-lru eviction policy: if memory ever fills, only keys with a TTL (locations and cached friend lists) can be evicted, never the sharing flags or versions. We alarm long before that, at 70% memory.

Tracing an update: Alice walks to the library

Synthesizing vector architecture diagram...

One round trip to the cache. The script is the only writer of loc:{u}, so the sharing check and the write can't be separated by a toggle.

Tracing an open: Bob looks at the tab

Synthesizing vector architecture diagram...

On a friend-list cache miss, the API queries DynamoDB (pk = USER#4411, about 200 items) and refills the set only if fver is unchanged.

Alice at (37.7793, −122.4193) and Bob at (37.7880, −122.4075): Δφ = 0.0087°, Δλ = 0.0118°, and Haversine gives 1,418 m. Carol at (37.7599, −122.4148) is 3,190 m from Bob. (The API example in R1.4 is Alice's own view: Bob 1,418 m away and Carol 2,193 m.)

R1.7 Numbers

Targets

Traffic

Memory

Reads per open. 1 set read + 400 pipelined commands. At 500 opens a second that's about 200,000 commands a second, in 500 pipelines. We read the primary, not the replica, so a sharing change is seen at once; a node of this size handles a few hundred thousand pipelined reads a second (an assumption to load-test).

API fleet. We plan 1,000 requests a second per vCPU (an assumption). Peak is 3,333 + 500 ≈ 3,833 requests a second. We run 6 tasks of 1 vCPU, 2 per AZ; if an AZ is lost, 4 tasks carry 958 a second each.

Latency budget, nearby-friends P99 (dependent steps add):

Monthly cost (us-east-1 on-demand list prices, 730 hours a month):

R1.8 Trade-Offs

Polling on open vs live push

The product asked for "within a minute", so polling wins: stateless servers, no connection fleet. Round 2 asks for watching friends move, and that flips the answer.

In-memory TTL vs a database

R1.9 Failure Modes

R1.10 Pillar Check

R1.11 Round 1 Rubric and Follow-Ups

What a strong mid-level (L5) answer shows

• Keeps only the latest position, in memory, with a TTL, and says why history is a liability.
• Starts from the friend list (the small set), not from a geo search over strangers.
• Uses Haversine for distance.
• Makes the sharing switch airtight: a guarded write, a checked read, SET NX refills and a rebuild after failover.
• Adds up every delay to prove the freshness target, and ties the send interval to movement and battery.

Follow-up questions

1. "Why not just store locations in DynamoDB with a TTL?" Answer: it works, but its TTL deletes only "typically within a few days", so staleness still has to be checked on every read, and at our rate on-demand writes cost more than the cache. The data is disposable; a store that forgets on time fits it.

2. "A student unfriends someone. How long until the ex-friend stops seeing them?" Answer: the next open. The unfriend deletes both cached friend sets and bumps each user's fver, so no in-flight refill can write the old list back. The DynamoDB transaction removes both directions at once.

3. "What if two updates from the same phone arrive out of order?" Answer: the write script compares measured_at with the stored ts and keeps the newer one, so a delayed old update is rejected.

Interview gotchas from this round's wrong answers

---

Round 2 · Senior · "10M People Moving at Once"

~40 min · Senior SDE (L6) · 1 region, 3 AZs · 100M DAU · 10M connected on average, 15M at peak · 333K updates/s average, 500K peak · delivery P95 < 1 s · 99.99%

R2.0 Where We Left Off

This is what the candidate says aloud in the first 60 seconds of Round 2. If you're starting here, it's everything you need from Round 1.

Round 1 in 60 seconds. "We built 'friends nearby' for a campus: 100K students sharing at peak, 200 friends each, a 5 km radius, positions under a minute old. We keep only each user's latest position, in a Valkey hash with a 15-minute TTL, because history is a liability and the data is disposable. Bob's list starts from his friend list, not a geo search over strangers: one cached set of friend IDs, one pipelined batch read, Haversine, sort. A sharing flag guards both the write script and the read, and refills use SET NX, so turning sharing off is airtight even with updates in flight; after a cache failover we rebuild the flags from DynamoDB before serving. Phones send every 30 seconds while moving and every 5 minutes while still, with jitter and a server hint, and the list refreshes every 20 seconds, which keeps positions at most 55 seconds old. About $616 a month. Open costs: nothing is live, the list is polled, and privacy is all or nothing."

Architecture v1, compact

Synthesizing vector architecture diagram...

Round 1 in one picture: a stateless API over a small in-memory store; phones poll.

Round 1 step summary

Open costs: polling, no live map, all-or-nothing privacy, one small cache.

R2.1 The Scope Raise

Interviewer: "A social app with 100 million daily users wants this. People want to open a map and watch their friends move, live. They want an alert when a friend comes within a kilometer. Some want to share a rough location with some friends and nothing with others. And the whole thing must survive losing a data center."

Scope change

The "Not yet" list from R1.2 comes back: live push, fuzzy mode and proximity alerts are all in scope now.

R2.2 What Breaks in the Round 1 Design

The order we fix it in: connections first (2.1), then the fan-out math (2.2) and how updates are routed (2.3), then the cells we still need (2.4), privacy (2.5), alerts (2.6) and the reconnect storm (2.7). Sizing comes in R2.6.

R2.3 New Requirements and API Additions

The phone now holds one WebSocket (a long-lived, two-way connection that starts as an HTTPS request and then carries small messages called frames in both directions).

Connect

httpCopy
GET /v1/live HTTP/1.1
Host: live.nearby.example
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Authorization: Bearer <access token>

Up: my location (every 30 s while the map is live)

jsonCopy
{ "t": "loc", "lat": 37.7801, "lon": -122.4180, "acc_m": 9, "measured_at_ms": 1791216151000, "seq": 4821 }

Down: a friend moved, left, or hid

jsonCopy
{ "t": "friend_loc", "user_id": 1007, "lat": 37.7801, "lon": -122.4180, "distance_m": 1274, "mode": "precise", "measured_at_ms": 1791216151000 }

jsonCopy
{ "t": "friend_fuzzy", "user_id": 2230, "area": { "lat": 37.7735, "lon": -122.4183, "radius_m": 3700 }, "distance_band": "about 3 km" }

jsonCopy
{ "t": "friend_gone", "user_id": 1007, "reason": "out_of_range" }

jsonCopy
{ "t": "hint", "next_update_s": 60, "reason": "crowded_area" }

The JSON above is for readability. On the wire we use a compact binary encoding of the same fields: about 100 bytes up and 120 bytes down (the sizes R2.6 uses). JSON as shown is roughly twice that; the design doesn't change, only the bandwidth line.

Privacy per friend

httpCopy
PUT /v1/me/privacy HTTP/1.1
Authorization: Bearer <access token>
Content-Type: application/json
If-Match: "12"

{ "default_mode": "fuzzy",
  "exceptions": [ { "friend_id": 4411, "mode": "precise" },
                  { "friend_id": 7730, "mode": "ghost" } ] }

• Modes: precise (exact position), fuzzy (an area of a few kilometers, step 2.5), ghost (nothing at all).
• The response carries the new privacy version ("13"). If-Match stops two devices from overwriting each other's settings.
• A global "go ghost now" switch is default_mode: "ghost" with no exceptions.

Proximity alerts

httpCopy
PUT /v1/me/alerts HTTP/1.1
Content-Type: application/json

{ "notify_me_about": [1007, 5120], "radius_m": 1000 }

An alert about Alice needs Alice's permission too: she must be sharing precisely with you. Each user can watch at most 20 friends (a product limit that also bounds the engine's work).

R2.4 Design Evolution: From Polling to a Pruned Live Fan-Out

Step 2.1: Live Updates for 10M Users

Primitive: WebSocket, SSE and Long Polling

Step 2.2: The Fan-Out Would Be 133M Messages a Second

Step 2.3: How Does a Gateway Learn Which Updates to Deliver?

Primitive: Geospatial Indexing: Geohash, Quadtree and S2

Synthesizing vector architecture diagram...

One publish, one delivery per interested gateway, each from a node in that gateway's own AZ. The viewer's gateway makes the final distance decision: Dan is on the near channel (within 15 km) but outside 5 km, so his phone gets nothing.

Step 2.4: Hexagons or Squares?

Step 2.5: Fuzzy Mode and Ghost Mode

Step 2.6: A Friend Entered My 1 km Zone

Step 2.7: An AZ Failed and 3.3M Phones Reconnected

Drill: The Gateway Restart That DDOSed the Chat Fleet (why an instant reconnect crushes authentication and pub/sub is answered at the top of this step; why WebSocket and not SSE over HTTP/2 is answered in step 2.1)

Round 2 Step Summary

R2.5 Architecture v2

Synthesizing vector architecture diagram...

Phones hold a socket to a gateway. Each gateway runs the location script on the state cluster and publishes on the pub/sub cluster; deliveries come back from the pub/sub replica in the gateway's own AZ. Settings changes flow from DynamoDB into the cache and out as control messages, twice if needed. The social app's existing friends service owns the friend graph; we cache it.

Key layout on the state cluster

Channels on the pub/sub cluster: n:{u}, f:{u}, z:{u} per user; g:{gw} per gateway for control messages and alerts.

Tracing a moving user: Alice walks 145 m, and two nearby friends see it

Alice moves from (37.7793, −122.4193) to (37.7801, −122.4180). Her friends online: Bob and Carol (near channel, precise), Dan in Oakland (near channel: 13.2 km is within 15 km), Frank in San Jose (far channel: 67.9 km), Erin (fuzzy).

Synthesizing vector architecture diagram...

Alice moved only 145 m, so her far anchor and her fuzzy cell (86283082fffffff) are unchanged: Frank and Erin get nothing. One publish, two gateway deliveries, two phone frames.

Tracing a ghost switch with an update in flight

1. 20:00:00.000: gateway 17 runs Alice's location script; it returns pv 12.
2. 20:00:00.001: Alice taps "ghost". The settings API writes DynamoDB (pv 12 → 13, condition "pv is still 12"), then set:{u1007}, then publishes hide, pv 13 on her three channels at 20:00:00.004.
3. 20:00:00.005: gateway 17's publish of the update with pv 12 lands, after the hide.
4. Gateway 42 has already recorded pv 13 for Alice from the hide, so it drops the late update and removes Alice's pin from Bob's map. Her next update hits the script, which sees ghost and publishes nothing.

Tracing a reconnect

1. Gateway 42's task is replaced; Bob's socket closes.
2. Bob's app waits a random 1.7 s (attempt 1: uniform between 0 and 2 s), resolves the NLB, and reaches gateway 205, which is under its 80-a-second admission budget.
3. TLS resumes from the session ticket; the token is verified locally.
4. Gateway 205 reads friends:{u4411} (hit), then one pipeline of presence and settings for 400 friends: 41 online.
5. It subscribes to 41 channels (35 were already subscribed for other users on this gateway, so 6 new SSUBSCRIBEs), and publishes "4411 online" to the control channels of the 37 gateways holding his online friends.
6. It sends Bob a snapshot: Alice at 1,274 m and one more friend within 5 km. His own next update refreshes live:{u4411} within 30 s.

R2.6 Numbers and Cost

Traffic

Bandwidth

Memory, honestly

Gateways. 50K connections per task (assumption) × 200 tasks = 10M: the original figure. It leaves out two things. The peak is 15M, so 300 tasks; and if one AZ is lost, the other two must hold everyone, so each AZ needs half the peak: 7.5M ÷ 50K = 150 tasks per AZ, 450 at peak. On an average evening, the same rule gives 10M ÷ 2 ÷ 50K = 100 per AZ, 300 tasks, which is what we pay for on average (autoscaled on connection count).

State cluster. Planning figures (assumptions to load-test on cache.r7g.xlarge, 4 vCPU, 26.32 GiB): 100,000 script calls a second per primary, and about 1M pipelined key reads a second per node.

• Scripts: 500,000 a second at peak. With 6 shards, 83,000 per primary, under 100,000. An AZ loss promotes replicas but keeps 6 primaries.
• Reads at connect: 8,300 connects/s × 400 ≈ 3.3M a second, over 18 nodes ≈ 185,000 each. During a storm, admission allows 24,000 connects/s: 9.6M reads/s over the 12 surviving nodes ≈ 800,000 each, under the ceiling.
• Memory: ElastiCache reserves 25% by default, and we fill the rest to 80%: 28.3 GB × 0.75 × 0.8 ≈ 17 GB per shard. 53 GB ÷ 6 ≈ 8.9 GB per shard. 6 shards × 3 nodes (one per AZ) = 18 nodes.

Pub/sub cluster. Planning figure: 300,000 operations a second per cache.m7g.xlarge node (4 vCPU, 12.93 GiB), counting each delivery, each publish received by a node, and each subscribe (an assumption).

With 12 shards × 3 = 36 nodes, that's 170,000 per node. After losing an AZ, during the reconnect storm: 3.28M deliveries + 525K × 2 + 24,000 × 76 ≈ 1.82M subscribes + normal disconnect unsubscribes from surviving users (8,300 × 76 ≈ 0.63M) = 6.78M over 24 nodes ≈ 282,000 each, still under 300,000. Subscription memory: 86 GB ÷ 36 ≈ 2.4 GB per node.

Latency budget, delivery P95 (from Alice's send to Bob's screen; dependent steps add):

The two radio legs dominate and are outside our control; a phone whose radio has gone idle can take longer to wake. So we alarm on the server-side part (NLB in to socket write out, about 30 ms) and track the end-to-end number from app telemetry.

Availability. 99.99% of a 30.4-day month is 43,776 min × 0.0001 ≈ 4.4 minutes. Not 99.999% (5.26 minutes a year): one AZ loss alone costs the affected third of users a few minutes of reconnecting (step 2.7).

Monthly cost (us-east-1 on-demand list prices, 730 hours a month):

About $0.89 per thousand daily users a month. The biggest lines are the gateways (39%) and data transfer out (28%): the cost of holding 10M sockets and talking over them.

What it would cost to persist every ping. Writing each update to DynamoDB on-demand: 333,333 × 2,626,560 s ≈ 875B writes × $0.625 per million ≈ $547K a month; provisioned for the 500K peak, 500,000 WCU × $0.00065 × 730 ≈ $237K. The often-quoted "$100K+ a month" is true but low; either way it's several times this whole design, for data that's obsolete in 30 seconds.

R2.7 Trade-Offs

Per-friend vs per-cell channels (details in step 2.3)

H3 vs geohash (for our cell uses)

Push vs periodic polling (rough figures)

Our gateways vs API Gateway WebSocket APIs. From step 2.1: about $38K a month against about $2.2M, because API Gateway bills every message and our fan-out produces 667K frames a second. The managed option wins only at small scale, or where there's no team to run the fleet.

R2.8 Failure Modes

R2.9 Production Gotchas

R2.10 Pillar Check

R2.11 Round 2 Rubric and Follow-Ups

What a strong senior (L6) answer shows

• Proves the fan-out explosion with numbers and prunes it, labeling each assumption.
• Says where each filter runs and why (online by subscription; nearby at the viewer's gateway, which already knows the viewer's position).
• Compares per-friend and per-cell channels on fan-out, privacy and churn, and picks one.
• Knows classic pub/sub doesn't scale in cluster mode, and uses sharded pub/sub.
• Verifies cell sizes instead of repeating "k = 2 covers 5 km".
• Enforces privacy on the server before fan-out, and handles the ghost-mode race with a version.
• Sizes the gateway fleet for peak and AZ loss, and designs the reconnect storm away.

Follow-up questions

1. "Why not have Alice's side compute distances to her online friends and send only to the nearby ones?" Answer: her side doesn't know where they are. It would have to read 40 friends' positions per update, 13.3M reads a second. The viewer's gateway already knows the viewer's position for free, because the viewer's own updates pass through it. The near/far tiers get most of the benefit of sender-side pruning without the reads.

2. "A user has 5,000 friends. What changes?" Answer: about 500 are online, so connecting costs 5,000 presence reads and up to 500 subscriptions, and their friend set exceeds our raised intset limit only above 5,000. The fan-out per update is still bounded by near-tier subscribers. We cap friends at 5,000 as a product rule, and very large accounts (public figures) don't get location sharing with all followers anyway.

3. "How do you know the 5% 'nearby' assumption is right?" Answer: we measure frames per update and internal deliveries per update at the gateways. If frames per update drifts from 2 toward 4, egress and gateway CPU double; the alarm is on the ratio, not just the totals.

Interview gotchas from this round's wrong answers

---

Round 3 · Architect · "Global, Private by Design, and Battery-Friendly"

~45 min · Principal (L7) · 4 regions · 50M connected at the sum of regional peaks · 783K updates/s at those peaks · delivery P95 < 1 s · 99.99% per region · privacy by default · a battery budget

R3.0 Where We Left Off

Round 2 in 60 seconds. "We serve 100M daily users from one region: 10M phones connected on average, 15M at peak, each sending every 30 seconds, so 333K updates a second, 500K at peak. Phones hold WebSockets to Fargate gateways behind an NLB with a TCP listener, up to 50K sockets per task and 450 tasks at peak so two AZs can carry everyone. Naive fan-out is 133M messages a second; we prune to online friends by subscription and to friends within 5 km at the viewer's gateway, which already knows the viewer's position: 667K frames a second. Routing uses per-friend channels on Valkey sharded pub/sub, with near, far and fuzzy channels per user, so the far-away majority of friends costs almost nothing, and gateways subscribe on the replica in their own AZ. We compared per-cell channels and rejected them: strangers' positions on every gateway and churn as people move; and k = 2 H3 rings don't cover 5 km anyway. Privacy is decided before fan-out, by channel; fuzzy is a resolution-6 cell with hysteresis; a privacy version makes ghost mode win every race. Alerts run in the sharer's pipeline with hysteresis and fire exactly once. Reconnect storms meet full jitter and admission before TLS. About $88.7K a month. Open costs: one region; friends on other continents; no consent model; no history; nothing against stalking; and a fixed 30-second interval that ignores the battery."

Architecture v2, compact

Synthesizing vector architecture diagram...

Round 2 in one picture: gateways write through one script and route through per-friend channels; settings flow in from DynamoDB.

Round 2 step summary

Open costs: a single region; cross-continent friends; no consent or history; no stalking defenses; a fixed interval.

R3.1 The Scope Raise

Interviewer: "We're global now: about a third of a billion daily users on every continent, 50 million connected at peak. People travel, and their friends live everywhere. Regulators in many countries treat precise location as sensitive personal data. Users keep asking for a trip history. Our safety team is worried about one scenario above all: an abusive partner who gets added as a friend to track someone. And the battery team has handed us a hard budget."

Scope change

R3.2 What Breaks in the Round 2 Design

R3.3 New Requirements and API Additions

Tokens carry routing. The access token names the user's home region and fallback home, so any gateway can route without a lookup:

jsonCopy
{ "sub": "u1007", "home": "us-east-1", "fallback": "ap-northeast-1", "data_region": "us-east-1", "exp": 1791219751 }

Consent records (append-only; one record per decision):

httpCopy
POST /v1/me/consents HTTP/1.1
Content-Type: application/json

{ "purpose": "location_sharing", "granted": true, "text_version": "2026-09", "surface": "onboarding_step_3" }

jsonCopy
{ "consent_id": "c_8f2a", "purpose": "location_sharing", "granted": true, "recorded_at": "2026-10-05T14:10:02Z" }

Share with a friend, for a while:

httpCopy
POST /v1/me/shares HTTP/1.1
Content-Type: application/json

{ "friend_id": 4411, "mode": "precise", "duration": "until_end_of_day" }

jsonCopy
{ "share_id": "s_19c4", "friend_id": 4411, "mode": "precise", "expires_at": "2026-10-05T23:59:59-07:00", "pv": 31 }

Durations: 1h, until_end_of_day, 24h, until_i_stop. The last one needs an explicit extra confirmation.

Location history:

httpCopy
PUT /v1/me/history HTTP/1.1
Content-Type: application/json

{ "enabled": true, "retention_days": 90 }

httpCopy
DELETE /v1/me/history HTTP/1.1

jsonCopy
{ "status": "deleted", "readable_until": null, "unrecoverable_after": "2026-10-12T14:00:00Z", "bytes_removed_by": "2026-10-06T14:00:00Z" }

Who has been looking:

httpCopy
GET /v1/me/viewers?since=2026-10-01 HTTP/1.1

jsonCopy
{ "viewers": [ { "friend_id": 7730, "view_sessions": 23, "first_shared": "2026-10-03" } ] }

"Locate now" (asks a friend's phone for a fresh fix): POST /v1/friends/1007/locate, at most 3 an hour per pair, and the friend is told each time.

R3.4 Design Evolution: Global, Private and Battery-Aware

Step 3.1: Friends in Different Regions

Primitive: Cloud Disaster Recovery and Multi-Region Active-Active

Synthesizing vector architecture diagram...

Alice's data stays with her home region even when she doesn't. Her updates cross the Atlantic and come back to Pierre's gateway; Pierre's updates reach her locally.

Step 3.2: Precise Location Is Regulated Data

Step 3.3: Opt-In Trip History

Step 3.4: Someone Uses the Feature to Stalk a Person

Step 3.5: The Battery Budget

Synthesizing vector architecture diagram...

The phone's motion states. Only Walking and Driving poll GPS on a timer; Stationary waits for the OS to report a move, plus a 5-minute heartbeat. Every transition waits 3 minutes, so a red light doesn't count as parking.

Step 3.6: A Region Is Down

Round 3 Step Summary

R3.5 Global Architecture

Synthesizing vector architecture diagram...

One regional stack. Everything about a user lives in their home region's clusters, except settings and consents, which every region needs and which replicate through the global table. Dotted lines leave the region: forwarding for travelers and cross-region friends, and settings replication. History never leaves its data region.

Tracing a traveler's update: Alice (home us-east-1) in Paris, and Pierre sees her

Synthesizing vector architecture diagram...

About 180 ms more than a local update. Alice's position never touches an EU data store; it passes through EU gateways in memory only.

Tracing a stalking-risk alert

1. Sam became Maya's friend 2 days ago; Maya shared precisely "until I stop" (after the confirmation).
2. Between 01:00 and 03:40, Sam opens the map 23 times. Each time, Sam's gateway adds a new session ID to views:{u5120}:{7730}:20261005.
3. The share is younger than 7 days and it's night, so the thresholds are 5, 10 and 20. The 5th add returns 1 and makes the size 5: the gateway emits one event, and the safety service notifies Maya: "Sam has checked your location 5 times tonight. Stop sharing?" The 10th and 20th adds do the same, if she hasn't acted.
4. A retried add of the same session returns 0 and emits nothing, so Maya gets one notice per threshold, not a flood.
5. Maya taps "stop sharing with Sam": her settings pv goes up, the hide goes out, and Sam's gateway drops Maya within a second.

Tracing a region failover: us-east-1 fails at 09:00 UTC

Synthesizing vector architecture diagram...

No data was restored. The user's state was rebuilt at a home every gateway agrees on, even though latency routing sent the phone to Frankfurt.

R3.6 Numbers and Cost

Traffic per region

Internal deliveries per user per second: 6 near subscribers × 0.01567 + 34 far or fuzzy ÷ 1,800 ≈ 0.113 (Round 2's assumptions, with the new update rate). The 50M is the sum of each region's own peak; the peaks come at different hours, so fewer are connected worldwide at any one moment. Daily users: 33.3M ÷ 10% ≈ 333M.

What each region must absorb. If a region fails, its users spread over the other three by fallback home. The worst case is a 15M region failing at its peak: +5M for each survivor. Each region is sized for the larger of (a) its own peak with one AZ lost and (b) its own peak plus 5M with all AZs up. We don't plan for both at once.

Gateways (50K per task; one AZ lost means two AZs carry the peak):

For Tokyo and Singapore, (b) lands exactly at 50K per task, so a failover at their peak also triggers a scale-out; admission control holds the line while tasks start.

State clusters (cache.r7g.xlarge; 100K scripts/s per primary; 17 GB usable per shard):

Pub/sub clusters (cache.m7g.xlarge, 300K ops/s per node; ops = deliveries + publishes received by each node + subscribes and unsubscribes at 76 × 2 per connect, with 30-minute sessions):

Three nodes per shard means one per AZ in every region, so the node counts are already whole per AZ.

Cross-region volume (monthly averages; 30.4-day month = 2,626,560 s):

The surprise is the last line: presence reads at connect are 62% of cross-region bytes, more than all live traffic. The lever is longer sessions (fewer connects) or a small per-region mirror of "who is online" for users with friends elsewhere; we note it rather than add it now.

Inter-region transfer is billed at the sending region: $0.02/GB from us-east-1 and eu-central-1, $0.09/GB from ap-northeast-1 and ap-southeast-1 (list prices). Assuming 60% of the bytes leave the US and EU regions: 169 TB × $0.02 + 113 TB × $0.09 ≈ $3,380 + $10,170 ≈ $13.5K.

History storage (opted in: we assume 5% of users):

Egress to phones (average frames 2 × updates, 220 B each, plus up to 60 B of pings per user per minute):

Monthly cost (on-demand list prices per region, 730 hours a month):

About $0.85 per thousand daily users a month, a little below Round 2's $0.89: the battery work halved the update rate per user, which paid for the extra regions. The gateways are 47% of the bill, and egress 19%.

Latency, delivery P95

R3.7 Trade-Offs

Home region vs local processing

We pick the home region: only 3% of users travel at a time, and a deterministic location is what makes both routing and failover simple.

Default privacy modes vs engagement

We recommend "nothing until chosen, precise only by explicit choice, and shares expire by default", and name it as a product decision the safety team owns.

Update frequency vs battery

What changed from Round 1. Round 1 answered "which friends are near?" with one cache and a poll. Round 3 answers it with four regions of gateways and pub/sub that route by friendship, forget positions within minutes, and send only what someone is looking at. The core never changed: start from the friend list, keep only the latest position, and let the viewer's side decide distance.

R3.8 Failure Modes

R3.9 Runbook and Incident Response

Golden signals, per region OPS 8 · REL 6

Reconnect-storm procedure REL 5

1. Confirm it's a storm: new connections and admission rejects up, pub/sub subscribe rate up.
2. Don't raise admission limits first. Check pub/sub and state CPU; if they're under 70%, raise admission by 20% at a time.
3. Scale the gateway service out; new tasks add admission capacity without raising any single task's rate.
4. If a bad deploy caused it, stop the rollout; planned drains spread the rest.
5. Watch reconnect success, not only connection counts: phones stuck in backoff show up as a lower update rate.

Region return procedure (restore order before traffic comes back) REL 13

1. Keep the region out of DNS: its health-check endpoint reports healthy only after the steps below.
2. Flush its state and pub/sub clusters: presence, gw fields and subscriptions from before the outage are all wrong.
3. Check the settings global table replica has caught up (ReplicationLatency back to normal), then flush the region's settings caches.
4. Restart the change feeds that fill our caches: re-enable the Lambda event source mapping on the region's settings stream (it resumes from its checkpoint; stream records older than 24 hours are gone, which the cache flush in step 3 already covers), and resume the friend-graph event consumer.
5. Flip the region-status document to up with a start time. Gateways move users back in waves: a user's effective home becomes the recovered region when (hash of user ID mod 20) is below the minutes since the start time, so every gateway agrees on each user, and 5% move per minute. Gateways re-subscribe; phones stay connected.
6. Let the health check pass. Over the next 30 minutes, gateways in other regions drain home users with planned reconnects, so latency routing brings them home.

Go deeper: CLI playbook

Plain commands an on-call engineer runs one at a time. Replace names, IDs and ARNs with real ones.

textCopy
# 1. Alarms firing in a region
aws cloudwatch describe-alarms --region eu-central-1 --state-value ALARM --alarm-name-prefix nearby-

# 2. Active connections on a gateway NLB, per minute
aws cloudwatch get-metric-statistics --region eu-central-1 --namespace AWS/NetworkELB --metric-name ActiveFlowCount --dimensions Name=LoadBalancer,Value=net/nearby-gw/0123456789abcdef --start-time 2026-10-05T09:00:00Z --end-time 2026-10-05T09:30:00Z --period 60 --statistics Average

# 3. Gateway service state and emergency scale-out
aws ecs describe-services --region eu-central-1 --cluster nearby --services gateway
aws ecs update-service --region eu-central-1 --cluster nearby --service gateway --desired-count 600

# 4. Pub/sub and state clusters
aws elasticache describe-replication-groups --region eu-central-1 --replication-group-id nearby-pubsub
aws elasticache describe-replication-groups --region eu-central-1 --replication-group-id nearby-state

# 5. Health check status for a regional endpoint
aws route53 get-health-check-status --health-check-id 1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d

# 6. Settings global table replicas and replication lag into us-east-1
aws dynamodb describe-table --region eu-central-1 --table-name NearbySettings
aws cloudwatch get-metric-statistics --region eu-central-1 --namespace AWS/DynamoDB --metric-name ReplicationLatency --dimensions Name=TableName,Value=NearbySettings Name=ReceivingRegion,Value=us-east-1 --start-time 2026-10-05T09:00:00Z --end-time 2026-10-05T10:00:00Z --period 60 --statistics Average

# 7. Re-enable the settings stream consumer in a recovered region
aws lambda list-event-source-mappings --region us-east-1 --function-name settings-cache-updater
aws lambda update-event-source-mapping --region us-east-1 --uuid 14e0db71-5d35-4eb5-b481-8945cf9d10c2 --enabled

# 8. Deploy the region-status document
aws appconfig start-deployment --region eu-central-1 --application-id abc1234 --environment-id def5678 --deployment-strategy-id AppConfig.AllAtOnce --configuration-profile-id ghi9012 --configuration-version 42

R3.10 Pillar Check

R3.11 Round 3 Rubric and Follow-Ups

What an architect (L7) answer adds over L6

• Places each user's live data in a home region and forwards travelers, instead of replicating live state.
• Knows latency routing doesn't send users to a chosen standby, and makes failover deterministic with a fallback home every gateway computes the same way.
• Rebuilds ephemeral state rather than failing it over, and restores order (flushes, stream catch-up) before traffic returns.
• Treats location as regulated data: minimization, consent records, purpose limits, retention that doesn't depend on TTL timing.
• Designs against abuse by a trusted friend, not only by outsiders.
• Ties update frequency to motion and to whether anyone is watching, and keeps the far-channel guarantee intact while doing it.
• Finds the surprising cost (presence reads across regions), not only the obvious ones.

Follow-up questions

1. "Why not fail live state over with ElastiCache Global Datastore?" Answer: Global Datastore copies from one primary region to secondaries, so every update of every user would cross regions, and the copy of a location that's minutes old is useless anyway. Phones rewrite their state within one update interval; rebuilding is cheaper and simpler than replicating.

2. "A user is homed in Europe but has lived in Tokyo for six months. What happens?" Answer: after 30 days of connections mostly from Tokyo, we re-home them: the next token says home: ap-northeast-1, the gateway publishes a control message, and friends' gateways re-subscribe there. Their history stays in their data region unless they move it, which is a separate, explicit step.

3. "The safety team wants to see the positions behind a stalking report." Answer: we don't have them: live positions expire in 10 minutes and there's no trail unless the victim opted into history, and history is readable only with her key. What we have is who shared with whom, when, and how often they viewed. That's a deliberate trade-off, and legal process goes through counsel.

Interview gotchas from this round's wrong answers

---

Loop Closer: Interview Strategy for All Three Rounds

How to Run Each 60-Minute Round

For how to spend a single 45-minute round, see the 45-minute interview blueprint. For more on connection fleets, see the chat loop.

The Two Sentences That Matter Most

• Opening any round: "Everyone moves and every update could go to hundreds of friends, so I'll keep only each person's latest position in memory, start every question from the friend list rather than from space, and let the viewer's side decide distance."
• When scale arrives: "I'll prune the fan-out to friends who are online, by subscription, and nearby, at the viewer's gateway, route by friendship rather than by cell so strangers' positions never move, and enforce every privacy mode on the server before anything fans out."

Well-Architected Review Sheet

Interviewers rarely ask "which pillar is this?". They ask the pillar's question in plain words. Rehearse one sentence per row.

Rubric Across Levels