Design Nearby Friends Real-Time Location Service

1. Problem Statement & Scope Clarification

System Mission

Design a real-time, high-throughput location sharing and proximity alerting service (similar to Apple Find My, Snapchat Snap Map, and Zenly) capable of continuously ingesting live GPS telemetry from tens of millions of concurrent mobile devices, computing pairwise proximity ($< 5\text{ km}$) across complex social graphs, and delivering real-time map updates with minimal mobile battery consumption.

Functional Requirements

1. Periodic Location Broadcast (UpdateLocation): Ingest mobile GPS coordinates every 30 seconds when the app is active in foreground/background.
2. Nearby Friends Query (GetNearbyFriends): Retrieve a real-time list of mutual friends within a $5\text{ km}$ radius, along with distance, bearing, and last-updated timestamp.
3. Proximity Push Notifications: Alert users when a mutual friend enters their designated proximity zone ($< 1\text{ km}$).
4. Privacy & Ghost Mode Controls: Support granular privacy toggles (Precise Location, Blurred/Fuzzy City-Level, Ghost Mode / Invisible).
5. Battery-Aware Movement Gating: Dynamically adjust GPS sampling rates based on device motion states (Stationary, Walking, Driving).

Non-Functional Requirements (SLAs & SLOs)

• High Ingestion Throughput: Ingest peak of $> 500,000\text{ GPS updates/sec}$.
• Propagation Latency: Friend location updates delivered via WebSocket in $< 2.0\text{ seconds}$.
• Availability: $99.999\%$ uptime SLA.
• Data Ephemerality: Live GPS coordinates are purely ephemeral (10-minute TTL in RAM); zero long-term location breadcrumbs stored on disk.

2. Capacity & Scale Estimation (Back-of-the-Envelope Math)

User Scale & Ingestion QPS

• Daily Active Users (DAU): $100,000,000$ ($100\text{M DAU}$).
• Concurrent Active Broadcasters: $10,000,000$ ($10\text{M active devices}$).
• Average Broadcast Frequency: 1 ping every 30 seconds.
• Average Ingest QPS: $\text{Average Ingest QPS} = \frac{10 \times 10^6\text{ devices}}{30\text{ sec}} \approx \mathbf{333,333\text{ updates/sec}}$
• Peak Ingest QPS ($1.5\times$ multiplier): $\text{Peak Ingest QPS} \approx \mathbf{500,000\text{ updates/sec}}$

The Quadratic Fan-Out Disaster Proof

If an average user has $400\text{ mutual friends}$, publishing every GPS update to all friends yields: $\text{Naive Fan-Out Delivery Rate} = 333,333\text{ updates/sec} \times 400\text{ friends} = \mathbf{133,333,200\text{ msgs/sec}}$ Broadcasting 133 Million WebSocket messages per second is economically and computationally infeasible.

Mitigation via Mutual Cell Pub/Sub Filtering

Instead of blind fan-out, we only propagate location updates to friends who are:

1. Currently Online and Connected to WebSockets ($\approx 10\% = 40\text{ friends}$).
2. Located in the Same or Adjacent Uber H3 Hexagonal Cells ($\approx 5\% = 2\text{ friends}$). $\text{Optimized Fan-Out Delivery Rate} = 333,333 \times 2 = \mathbf{666,666\text{ msgs/sec}}$ This $200\times$ reduction makes real-time delivery completely tractable on a modest Redis Pub/Sub cluster.

Memory Sizing for Live Geospatial State

• Record size per user in Redis: user_id (16B), lat (8B), lon (8B), h3_index (8B), timestamp (8B) $\approx 48\text{ bytes}$. $\text{Active Memory} = 10,000,000\text{ users} \times 48\text{ bytes} \approx \mathbf{480\text{ MB RAM}}$ Even with 3x replication and social graph caching, the entire live geospatial index requires $< 10\text{ GB RAM}$.

3. High-Level Architecture & AWS Component Mapping

Interactive Architecture Diagram
100%Fit100%
Synthesizing vector architecture diagram...

4. API Interface Design & Wire Protocols

1. Client Location Update Frame (WebSocket JSON)

jsonCopy
{
  "action": "UPDATE_LOCATION",
  "latitude": 37.774929,
  "longitude": -122.419416,
  "accuracy_meters": 8.5,
  "altitude_meters": 42.0,
  "speed_mps": 1.4,
  "privacy_mode": "PRECISE", // "PRECISE", "FUZZY_CITY", "GHOST"
  "timestamp_client_epoch_ms": 1767225600120
}

2. Server Downlink Location Broadcast Frame

jsonCopy
{
  "event": "FRIEND_LOCATION_UPDATE",
  "friend_id": "usr_alice_101",
  "latitude": 37.774929,
  "longitude": -122.419416,
  "distance_meters": 1240,
  "bearing_degrees": 45.2,
  "last_updated_epoch_ms": 1767225600120
}

5. Geospatial Indexing & Uber H3 Hexagonal Grid Architecture

The earth's surface is partitioned into Uber H3 Hexagons at Resolution 7 (Average edge length $\approx 1.22\text{ km}$, Area $\approx 5.16\text{ km}^2$):

textCopy
H3 Resolution 7 Cell Hierarchy:
Center Hexagon (Cell 0) surrounded by 6 Immediate Neighbor Hexagons (k-ring radius = 1)
Total 7 Hexagons cover a ~5 km Proximity Radius seamlessly

Interactive Architecture Diagram
100%Fit100%
Synthesizing vector architecture diagram...