250k/s
location updates at the 9 pm peak
Assume 6% of 120M opted-in users have the app open: 7.2M phones. Sending every 15 s when moving and 60 s when still halves a fixed timer.
Who are the candidates?
Bad: Geo index, then filter
A 10 km circle in Bengaluru: ≈ 200,000 candidates to keep ≤ 30 friends.
Good: Friend graph picks
Read 30 sharing friends’ locations. Same cost in a village or Koramangala.
Every user gets a channel. Asha publishes once.
Rohan’s server subscribes to his 30 sharing friends’ channels. It already knows where Rohan is, so it computes the distance in memory.
Add Redis nodes, and pub/sub gets no faster.
A classic PUBLISH is copied to every node: more copies, not capacity. Sharded SPUBLISH keeps loc:asha on the one shard that owns it. About 20 primaries.
Asha removes Rohan. The “revoke” goes over at-most-once pub/sub and is lost. Her updates keep coming.
Lossless permissions
Every update carries Asha’s settings version. A newer one makes Rohan’s server re-check before showing anything.
2015: Nearby Friends users found within 5 metres
A fake friend measures distances from three spots and intersects the circles. Rounding barely helps: they move until the number flips.
The fix: snap first, then compute
- Snap both people to 1 km cell centres
- Use only your own verified, last-reported location
- Beyond 10 km, show only a city
- Sort by bucket, then name
Remember
Friends, not the map, pick the candidates. Publish each update once on the user’s channel; the viewer’s server computes a bucket from 1 km cells. Permissions ride versions, not the lossy channel.