hard general · part of Practice Questions · Senior SWE Roadmap
Requirements to clarify
- Functional: show a user which of their friends are currently nearby, updating in near real-time as people move.
- Non-functional: extremely high write volume (every user’s location streams in continuously), but only a tiny fraction of pairs (actual friends) ever need to be compared — this shapes the whole design.
Core components
- Location ingestion: client apps stream periodic location updates through a message queue/pipeline rather than direct synchronous writes, absorbing the high write volume.
- In-memory geospatial index per shard: recent locations held in memory (e.g., grouped by geohash cell) rather than a full DB round-trip, since only “recent” location matters and old data can be discarded/overwritten (see Design a Proximity Service).
- Friend-scoped computation: instead of a global proximity query, only check proximity within each user’s friend list — fan out location updates to friends who are actively viewing the feature (via a pub/sub/WebSocket push), not a global broadcast.
- Push to active viewers only: only compute/send updates for friends who currently have the feature open, drastically cutting unnecessary work.
Key tradeoffs
- Trading strict real-time accuracy for system load: updates every few seconds (not truly instantaneous) is usually an acceptable, much cheaper approximation.