Loading...
External:
Internal:
User Table (SQL):
User City List (NoSQL):
User sends request -> Loadbalancer -> Server -> Check cache and return if cache hit continue if cache miss -> serverside sends request to third party API -> Get weather -> Store weather in cache with TTL -> Return weather
User sends request -> Loadbalancer -> Server -> Update document for user's list of cities
Read heavy -> use DB replicas, synchronous
Flow for getting weather:
User sends request -> Loadbalancer -> Server -> Check cache and return if cache hit continue if cache miss -> serverside sends request to third party API -> Get weather -> Store weather in cache with TTL -> Return weather
Flow for adding city:
User sends request -> Loadbalancer -> Server -> Update document for user's list of cities
Shard the UserListDB
Create replicas, to reduce strain from so many reads on a single DB
Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...
Explain any trade offs you have made and why you made certain tech choices...
Too many requests at a time
-> Too many POST requests to update DB
-> Too many reads -> Pressure is alleviated from replicas and cache
Add additional more in depth information about each city
Requests users have to enhance their experience