Loading...
List functional requirements for the system (Ask interviewer if stuck)...
Estimate the scale of the system you are going to design...
Define what APIs are expected from the system...
GET /weather?latitude=&longitude=
Users will send the latitude and longitude of their current location or whichever location they'd like to get weather information from and the API will respond with a json object containing information, like temperature, AQI, humidity, precipitation, etc. with units in the metric system.
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...
We're not utilizing any relational databases in this design, but we'll use a Redis cache to store Weather API responses. We'll evict entries using the LRU algorithm. The key in the key-value store will be the latitude and longitude of a location. The value will be the response from the Weather API.
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design...
I'll start by having client requests get routed through an ELB to a number of stateless servers. The servers themselves will handle these GET requests from users and fetch weather information for a specific location from the external weather API. We can consider adding a in-memory cache like Redis between the servers and the external weather API with a short TTL (say, 5 minutes) to help alleviate hitting the external API rate limit.
If we have 10k users who can send max of 1000 requests per hour, we'll expect an upper bound of 10 million requests per hour. We can first try horizontal scaling by automatically increasing the number of servers behind the ELB when we hit bursts of traffic. It is also likely that users will fetch weather information for their current location, so we can consider replicating this service to different geographical locations and route users to their nearest system
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
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...
Try to discuss as many failure scenarios/bottlenecks as possible.
Our reliance on the external API is a single point of failure. If the external API goes down, our service goes down as well.
The user request volume is a potential bottleneck as well if there's a burst of traffic that our servers won't be able to handle.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
If we hit the weather API rate limit, we can consider serving users weather information close to location they requested. For example, we can consider a radius of 1 mile from the requested location as information that's accurate enough and serve that information to users.