Understand the Problem
In this chapter, we design a proximity service. A proximity service is used to discover nearby places such as restaurants, hotels, theaters, museums, etc., and is a core component that powers features like finding the best restaurants nearby on Yelp or finding k-nearest gas stations on Google Maps. Figure 1 shows the user interface via which you can search for nearby restaurants on Yelp 1. Note the map tiles used in this chapter are from Stamen Design 2 and data are from OpenStreetMap 3.
Step 1 – Understand the problem and establish design scope
Yelp supports many features and it is not feasible to design all of them in an interview session, so it’s important to narrow down the scope by asking questions. The interactions between the interviewer and the candidate could look like this:
Can a user specify the search radius? If there are not enough businesses within the search radius, does the system expand the search?
That’s a great question. Let’s assume we only care about businesses within a specified radius. If time allows, we can then discuss how to expand the search if there are not enough businesses within the radius.
What’s the maximal radius allowed? Can I assume it’s 20 km (12.5 miles)?
That’s a reasonable assumption.
Can a user change the search radius on the UI?
Yes, we have the following options: 0.5km (0.31 mile), 1km (0.62 mile), 2km (1.24 mile), 5km (3.1 mile), and 20km (12.42 mile).
How does business information get added, deleted, or updated? Do we need to reflect these operations in real-time?
Business owners can add, delete or update a business. Assume we have a business agreement upfront that newly added/updated businesses will be effective the next day.
A user might be moving while using the app/website, so the search results could be slightly different after a while. Do we need to refresh the page to keep the results up to date?
Let’s assume a user’s moving speed is slow and we don’t need to constantly refresh the page.
Functional requirements
Based on this conversation, we focus on 3 key features:
-
Return all businesses based on a user’s location (latitude and longitude pair) and radius.
-
Business owners can add, delete or update a business, but this information doesn’t need to be reflected in real-time.
-
Customers can view detailed information about a business.
Non-functional requirements
From the business requirements, we can infer a list of non-functional requirements. You should also check these with the interviewer.
-
Low latency. Users should be able to see nearby businesses quickly.
-
Data privacy. Location info is sensitive data. When we design a location-based service (LBS), we should always take user privacy into consideration. We need to comply with data privacy laws like General Data Protection Regulation (GDPR) 4 and California Consumer Privacy Act (CCPA) 5, etc.
-
High availability and scalability requirements. We should ensure our system can handle the spike in traffic during peak hours in densely populated areas.
Back-of-the-envelope estimation
Let’s take a look at some back-of-the-envelope calculations to determine the potential scale and challenges our solution will need to address. Assume we have 100 million daily active users and 200 million businesses.
Finished reading?
Mark it complete to track your progress.