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.

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 → To route users.

DDoS → To stop attacks early.

WAF → To filter malicious requests.

CDN → To reduce latency.

API Gateway → To manage and route APIs.

Load Balancer → To distribute traffic.

Redis → To cache frequently accessed data.

Database → To persist data.

Queue → To process tasks asynchronously.

Notification Service → To send alerts.

Analytics Service → To collect metrics.

Weather Service → To execute the business logic.

IdP → To authenticate users securely.

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

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.