Loading...
User can search establishments by name, category and location.
User can write comments to establishment.
The search results must be return in 2 second.
Write comments could be eventually consistency.
High availability.
Scalability.
Assume 10m daily active users
Read QPS: 10m / 100k = 100
Assume 10% users write one comment per day
Write QPS: 10m * 10% / 100k = 10
Storage estimation:
Assume we have 10m establishments in total.
Each establishment will need 1mb storage to store metadata, image and videos. We need to store 10m * 1mb = 10TB. We need 3 replicas. In total we need 30TB storage.
API:
GET search(user_id, location, category, keyword)
return list of establishments info
GET read_review(user_id, business_id, start, end)
return list of reviews
POST write_review(user_id, business_id, score, review_text)
return success/error
SQL DB will store relational structure information like establishment info, comment info.
Establishment Table:
id (primary key)
info fields
commentIds (reference id list of comment table)
Comment Table:
id (primary key)
info fields
establishmentId (reference key of Establishment table)
Document DB will store establishment doc and comment doc. Document DB will indexed multiple fields of establishment doc and comment doc to ensure fast text based search.
Quad Tree will store establishment's location info for fast location based search.
See diagram
Request from Client are forwarded to an appropriate service by load balance and API Gateway, according to the request URI.
Text Search Service handles search requests, using businesses data in Document DB and Cache. For example it could use elastic search to indexes multiple text fields and stored into shards to enable fast search.
Review Service writes reviews to SQL DB, Document DB. Message Queue is in between the service and the DB to protect the situation where sudden burst of writes happen.
search algorithm
- Search Service figures out a user's area using location.
- It looks up businesses using area, category, price range.
- We use multiple indices field in Document DB.
- Then, it does more fine grained search in quad tree for the nearest businesses, using locations.
- It then further refine the results using text based search of Elastic Search.
For the data store, Document DB like Mongo DB would be suitable because:
- User is on the edge of an area. -> Need to search user's own area + neighboring area.
- One area becomes so dense with businesses. -> Needed to divide the area further. Consistent hashing to allow re-partitioning by area.
- Burst of reviews (writes) to a particular business. -> Message Queue
- More scale in general -> Horizontally scale all components. Partition data using area.
*** Maintainability
- Monitor all components.
- Alerts on response time too slow, server resource issues, server crashes.
- Fault tolerance. Back up business data 3 ways (same data center, same region, different region for disaster recovery).
- Services are stateless. Duplicate them and have an automatic recovery. Cache, DB, message queue should have the same.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?