Loading...
A user could get nearby place of interest.
A restaurant could upload and report its positions
Service should have low latency in finding nearby restaurants
Service should have high data consistency.
10M DAU
10 queries / day
Read QPS: 1.1k
1M POI
Write QPS: ~11
Read heavy
We can use master-slave
get_nearby_poi(category, lon, lat, page_num)
{
page_num: int
poi: [
{
id:
review:
name:
avatar:
subcategory:
},
...
]
}
update_place_info(place_id, lon, lat, new_info)
get_place_info(place_id)
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...
LB is the service which balances the traffic to different servers.
When user requests the poi, the lb
We cannot search for long and lat in database. We could leverage geohash. Geohash is a mechanism to express a location using a string. It divides the whole world into grids. As the location comes closer, the geohash will have longer prefix. Therefore, we can leverage geohash prefix to search for the nearby locations.
Distributions for geohash could be even. Larger grid for suburb and smaller grid for urban.
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?