Requirements

Functional Requirements:

• The report must have graphics of the temperature through the days.
• Insights and analytics
• User-management: log in, logout. etc. etc
• See the weather in different places (type the city the user wants)
• See weather in current locations. (Humidity, wind, UV, pollen)
• see the weather of the current week.
• Real time weather alerts & notifications

Non-Functional Requirements:

• Low latency: Since the system will alert the user about a storm, tornado, idk it must have real time data.
• High availability: Since it's weather it must always be available.
• Real time data syncing: Since it's a weather system, it must a websocket to immidiatly yhr
• Global Availability: Users can request weather data for any supported city or geographic coordinates worldwide.
• Scalability: handling requests.

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

GET /weather

• Path: /weather?city={city_name}
• Method: GET
• Response:

{ "city": "Tokyo", "temperature": 22, "humidity": 65, "wind_speed": 12, "uv_index": 5, "timestamp": "2024-01-15T14:30:00Z"}

GET /forecast

• Path: /forecast?city={city_name}&days={1-7}
• Method: GET
• Response: Array of daily forecasts

GET /search

• Path: /search?q={partial_name}
• Method: GET
• Response: Autocomplete list of matching cities

POST /alerts/subscribe

• Path: /alerts/subscribe
• Method: POST
• Body:

{ "city": "Tokyo", "channels": ["push", "email"], "alert_types": ["storm", "heavy_rain", "extreme_temp"], "device_token": "abc123"}

• Response: { "subscription_id": "sub_456" }

DELETE /alerts/unsubscribe

• Path: /alerts/unsubscribe?subscription_id=sub_456
• Method: DELETE

High-Level Design

DNS → Route users.

DDoS → Stop attacks.

WAF → Filter malicious requests.

CDN → Reduce latency.

IdP → Authenticate users.

API Gateway → Manage APIs.

Load Balancer → Balance traffic.

Weather Service → Run business logic.

Location Service → Manage locations.

Notification Service → Send alerts and sever weather notifications.

WebSocket → Push real-time updates.

Queue → Process asynchronously.

Worker → Execute background jobs.

Redis → Cache data.

NoSQL → Store application data.

S3 → Store historical files.

Analytics → Generate insights.

NAT Gateway → Provide outbound Internet access.

External Provider → Provide weather data

The system reduces traffic during severe weather events by using real-time WebSocket notifications, eliminating the need for clients to continuously poll the API for updates.

The system implements idempotency using unique event IDs and validates timestamps to prevent duplicate or stale weather updates from overwriting newer data.

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

Detailed Component Design

The Weather Service first checks Redis for weather data using the location and forecast type as the cache key. If the data is not found, the service requests it from the external weather provider, stores the normalized response in Redis with a short TTL, and then returns it to the client.

The Weather Service will use an adapter pattern to integrate with external weather providers. Each provider will have its own adapter that converts the vendor-specific response into a common internal weather model. This allows the system to switch providers without changing the Weather Service business logic.