Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
List non-functional requirements for the system...
Estimate the scale of the system you are going to design...
Number of user : 100000 peak hours
API Request Rate: 5 request per session
Data Size: 5KB /response
Define what APIs are expected from the system...
1). fetch weather.
api-/weather/fetch
method-GET
query:
lat:-
long:-
response
{
"coord": {
"lon": 7.367,
"lat": 45.133
},
"weather": [
{
"id": 501,
"main": "Rain",
"description": "moderate rain",
"icon": "10d"
}
],
"base": "stations",
"main": {
"temp": 284.2,
"feels_like": 282.93,
"temp_min": 283.06,
"temp_max": 286.82,
"pressure": 1021,
"humidity": 60,
"sea_level": 1021,
"grnd_level": 910
},
"visibility": 10000,
"wind": {
"speed": 4.09,
"deg": 121,
"gust": 3.47
},
"rain": {
"1h": 2.73
},
"clouds": {
"all": 83
},
"dt": 1726660758,
"sys": {
"type": 1,
"id": 6736,
"country": "IT",
"sunrise": 1726636384,
"sunset": 1726680975
},
"timezone": 7200,
"id": 3165523,
"name": "Province of Turin",
"cod": 200
}
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...
Here, we are going to use a NoSQL database that will store vendor API or webhook responses. The data will be stored in the database with latitude, longitude, and a timestamp for historical retrieval.
data model
{
"_id": "5553a998e4b02cf7151190c9", // MongoDB's unique ID for the document
"location": {
"city": "New York City",
"state": "NY",
"country": "USA",
"latitude": 40.7128,
"longitude": -74.0060
},
"current_weather": {
"timestamp": "2025-09-06T11:00:00Z",
"temperature": 20.5,
"humidity": 65,
"wind_speed": 15,
"wind_direction": "NW",
"condition": "Partly Cloudy",
"icon_code": "02d"
},
"daily_forecasts": [
{
"date": "2025-09-07",
"temp_max": 22,
"temp_min": 15,
"condition": "Rainy",
"icon_code": "09d"
},
{
"date": "2025-09-08",
"temp_max": 25,
"temp_min": 17,
"condition": "Sunny",
"icon_code": "01d"
},
// ... up to 7 days
],
"hourly_forecasts": [
{
"timestamp": "2025-09-06T12:00:00Z",
"temperature": 21.0,
"condition": "Cloudy",
"icon_code": "03d"
},
{
"timestamp": "2025-09-06T13:00:00Z",
"temperature": 21.5,
"condition": "Cloudy",
"icon_code": "03d"
},
// ... up to 24-48 hours
],
"historical_data": [
{
"timestamp": "2025-09-05T11:00:00Z",
"temperature": 18.2,
"humidity": 60,
"condition": "Cloudy"
},
{
"timestamp": "2025-09-05T10:00:00Z",
"temperature": 17.5,
"humidity": 58,
"condition": "Cloudy"
},
// ... many more entries
]
}
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...
In high-level design, we are going to create a weather service that is responsible for orchestrating the flow. The weather service will call the third-party service, and then the third party will call the vendor for data. The weather service will then put the data into Redis and a database. Redis will be used for quick responses to recent weather pulls based on latitude and longitude keys, while the database will contain all historical data. Based on vendor webhooks, the weather service will publish events to Kafka, and then the notification system will send real-time bad weather forecasts to users.
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...
Client Request: The client initiates a request with latitude and longitude, which is routed through an API Gateway to the weather service.
Orchestration: The weather service orchestrates the flow by calling a third-party service to fetch weather data from a vendor.
Data Storage & Response: The weather service stores the fetched data in both a NoSQL database for historical records and Redis for fast, recent data retrieval before responding to the client.
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...
This service's main responsibility is to orchestrate weather reporting functionalities. When a request is received, it first checks Redis. If the data isn't there, it initiates a call to the vendor, stores the response in Redis with a TTL (Time-to-Live) to decrease the number of vendor calls, and automatically handles cache invalidation. The service also publishes an event for a real-time weather forecast. For scaling, it uses Kubernetes (K8s) to handle autoscaling.
In case of an outage at the vendor's end, if data exists in Redis, we are going to return that. If not, we are going to queue these requests, and whenever the vendor comes back online, we will issue a real-time forecast from the Notification Service.
This service sends real-time weather forecasts to users. It polls data from a Kafka topic published by the Weather-Service, and then calls a vendor API to send real-time alerts like Firebase push notifications, SMS, and emails.
This service handles the integration of vendor APIs, making our weather service vendor-agnostic. Using the Factory design pattern, we can integrate with multiple vendors and transform their data into our own standardized data structure. Additionally, all vendor APIs will be equipped with Circuit Breakers.
Explain any trade offs you have made and why you made certain tech choices...
Try to discuss as many failure scenarios/bottlenecks as possible.
when our Thirdpaty service providers have down time and we need to provide ssls simility to them to our client.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?