Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)
the weather app needs to give specific info based on location
highly available and consistent, we want to see live updates
Estimate the scale of the system you are going to design...
Define what APIs are expected from the system...
get_weather(api_key,zip_code)
this is a GET request that authenticates with the API key and grabs information based on the location identifier. the api_key can also be fed into redis to incorporate rate limiting.
for each zip code, we can store the temperatures as a time series. many databases are optimized to store this kind of information, making it ideal for our case. We can store the previous day up to 2 weeks in the future. TimeScaleDB has built in methods for calculating highs and lows amongst other things, and therefore it stands as the best way to store this information
so for each zip code we have:
zip code (used as hash/key), latitude, longitude, timeSeriesObject (or a link to it), yearly high, yearly low,
a quadtree might work well for location based data. well probably be getting more than a single value from the weather server, I imagine wed get something like a JSON object with other factors like humidity, chance of precipitation, wind speed etc.. MongoDB would be great because we can store documents with historical data for each location.
one important thing here is caching. the most frequently requested places will most likely be places with high populations and also high tourism. I think the 10 most popular cities can be cached (LRU makes the most sense here) and this allows for lower latency.
we can use the OpenWeather API
it makes more sense to have a separate microservice that is periodicially checking for weather updates and updating as needed. Then when we make a request, itll fetch the information from the database. the microservice can be designed to be unique for each type of data. weather could be updated hourly but maybe humidity does not need to be updated as frequently. this difference provides less requests overall and makes the system more robust.
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...
the client sends a request with a zip code or some other location identifier. the server matches that identifier with the respective
user sends a location identifier to a load balancer which then goes to an application server. the server uses the get_weather api mentioned previously to grab the relevant data for that specific location. if its a popular location, it'll pull from the cache. If not, it will access MongoDB and TimeScaleDB to pull the relevant information. the application server can use a messaging service to handle multiple requests, as I imagine there will be quite a lot. this allows for other requests to be fulfilled while we are waiting for one (aka maybe a cache request can be filled while another is probing timeScaleDB).
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...
we can use a sliding window to keep track of moving averages for our data.
we can use redis as our caching layer. It provides a quick retreival of data for hotspots. LRU makes the most sense here since we are trying to cache the most commonly accessed places.
Explain any trade offs you have made and why you made certain tech choices...
Try to discuss as many failure scenarios/bottlenecks as possible.
if data is not found, we can return a not found error and do one or two retries. if not then we need to return an error to the user and log it for developers to see
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?