Understand the Problem
In this chapter, we design a scalable backend system for a new mobile app feature called "Nearby Friends''. For an opt-in user who grants permission to access their location, the mobile client presents a list of friends who are geographically nearby. If you are looking for a real-world example, please refer to this article 1 about a similar feature in the Facebook app.
If you read the Proximity Service chapter, you may wonder why we need a separate chapter for designing “nearby friends” since it looks similar to proximity services. If you think carefully though, you will find major differences. In proximity services, the addresses for businesses are static as their locations do not change, while in "nearby friends", data is more dynamic because user locations change frequently.
Step 1 – Understand the problem and establish design scope
Any backend system at the Facebook scale is complicated. Before starting with the design, we need to ask clarification questions to narrow down the scope.
How geographically close is considered to be “nearby”?
5 miles. This number should be configurable.
Can I assume the distance is calculated as the straight-line distance between two users? In real life, there could be, for example, a river in between the users, resulting in a longer travel distance.
Yes, that’s a reasonable assumption.
How many users does the app have? Can I assume 1 billion users and 10% of them use the nearby friends feature?
Yes, that’s a reasonable assumption.
Do we need to store location history?
Yes, location history can be valuable for different purposes such as machine learning.
Could we assume if a friend is inactive for more than 10 minutes, that friend will disappear from the nearby friend list? Or should we display the last known location?
We can assume inactive friends will no longer be shown.
Do we need to worry about privacy and data laws such as GDPR or CCPA?
Good question. For simplicity, don’t worry about it for now.
Functional requirements
-
Users should be able to see nearby friends on their mobile apps. Each entry in the nearby friend list has a distance and a timestamp indicating when the distance was last updated.
-
Nearby friend lists should be updated every few seconds.
Non-functional requirements
-
Low latency. It’s important to receive location updates from friends without too much delay.
-
Reliability. The system needs to be reliable overall, but occasional data point loss is acceptable.
-
Eventual consistency. The location data store doesn’t need strong consistency. A few seconds delay in receiving location data in different replicas is acceptable.
Back-of-the-envelope estimation
Let’s do a back-of-the-envelope estimation to determine the potential scale and challenges our solution will need to address. Some constraints and assumptions are listed below:
-
Nearby friends are defined as friends whose locations are within a 5-mile radius.
-
The location refresh interval is 30 seconds. The reason for this is that human walking speed is slow (average 3-4 miles per hour). The distance traveled in 30 seconds does not make a significant difference on the “nearby friends” feature.
-
On average, 100 million users use the “nearby friends” feature every day.
-
Assume the number of concurrent users is 10% of DAU, so the number of concurrent users is 10 million.
-
On average, a user has 400 friends. Assume all of them use the “nearby friends” feature.
-
The app displays 20 nearby friends per page and may load more nearby friends upon request.
Finished reading?
Mark it complete to track your progress.