Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
the app pulls the latest weather information
List non-functional requirements for the system...
Estimate the scale of the system you are going to design...
temperature - 5 bytes, updated hourly so 120 bytes per day
humidity, precipitation - 5 bytes each, updated every 4 hours so 30 bytes a day
150 bytes per day is super low, but we are storing historical data so over time we can imagine well get 150*365 = 5.4 MB per year. Still very low
Define what APIs are expected from the system...
get_temperature(user_id,locX, locY)
get_forecast(user_id,locC,locY)
user_id can be used for rate limiting and logging
locX and locY are coordinates
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...
To make the request flow as smooth as possible, a key:value type storage would be nice. However, to store historical data and keep trends, a database focused on time series would be even better. TimeScaleDB is a good choice
Location (maybe zip code or county)
Timestamp
Temp
Humidity
Chance of Precipitation
Extreme Condition (None, Storm, Flood etc.)
For frequently accessed weather data, a caching layer could be used to ensure that we have faster response times for the increased throughput. We'll also keep a backup DB incase ours goes down. Redis would be the best caching layer. We can use LRU caching to ensure that we only work with the most popular cities.
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. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
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...
For an individual temperature:
user -> Load Balancer -> Web server -> GET request for temperature based on location
for Forecast:
same as above but GET for past 7 days
In the event that we don't find the specified location, we can map it to the nearest coordinate system. If theres still no match, we need to return an error.
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 have a separate microservice that is continuously checking for data. Temperature can be checked every hour, but humidity and precipitation are less volatile and can be checked every 3-4 hours. By incorporating separate microservices, we can get scale each independently.
Another microservice could be checking for extreme weather effects. This could check more frequently, as those updates are more serious.
TimeScaleDB has built-in metrics for analyzing time series data, we could easily keep a running average, yearly highs/lows and other important metrics ready at hand. In the event that TimeScale does not have this, we could create another microservice to have this ready.
Explain any trade offs you have made and why you made certain tech choices...
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?