Requirements

Functional Requirements:

• Allow users to query current weather conditions (temperature, humidity, wind, etc.) for a specific city, coordinates, or region.
• Provide weather forecasts for upcoming days (e.g., 7-day or hourly forecast) so users can plan ahead.
• Enable users to look up weather by city name, zip code, or latitude/longitude coordinates.
• Push notifications, alerts, or live data updates to users when weather changes or severe events occur.

Non-Functional Requirements:

• Scalability - since DAU is 10-100 million, it should scale well.
• Available and reliable - users can query weather data any time of the day and from any locations, hence the application should be highly available and reliable.
• Good data accuracy - especially for current weather data.
• Low bandwidth or network usage - since it runs in the background and users can use this app on mobile data too.

API Design

Client needs the current weather data and the forecasted weather data to render to the user the weather details. So we'll be having 2 API's:

(i) API for current weather data:

/api/v1/weather/current?lat=3.4&long=5.6

/api/v1/weather/current?city=delhi

/api/v1/weather/current?pincode=110000

API response (JSON):

{

"temperature": "30C",

"humidity": "61%",

"precipitation": "81%",

"aqi": "130"

}

(ii) API for forecasted weather data:

/api/v1/weather/forecast?lat=3.4&long=5.6

/api/v1/weather/forecast?city=delhi

/api/v1/weather/forecast?pincode=110000

API response (JSON):

{

"day-forecast": {...},

"week-forecast": {...}

}

High-Level Design

1. User will be accessing app through mobile (IOS or Android).
2. Load balancer or API gateway will be there for routing requests through consistent hashing. It will do rate limiting and authentication too. All services will be distributed and horizontally scaled for fast response and caching is also there.
3. Weather reporting service will answer user API requests by providing current data, forecasted data, etc. It will take data from cache (Redis) mostly and if for some reason it is not there in cache, it will query on demand.
4. Weather query service can query the 3rd party API's periodically or on demand. When done periodically, it updates the weather in a message queue like Kafka. Messages from here are consumed by other services like weather data aggregation service (which updates the cache) and weather anomaly detection service which notifies the customer through push notifs.

Detailed Component Design

(i) DB and cache design:

DB

--> It will contain user data, session data and opt in / opt out preferences, etc.

--> This can be SQL DB like Postgre SQL since data is structured and unchanging.

Cache

--> This will store weather data.

--> We can use Redis. It will have key value pairs as city : weather data.

--> TTL can be few minutes and data will anyways keep getting refreshed by data aggregation service.

(ii) How will geohashing work?

--> We will be using 3rd party API's in order to convert the city names, pin codes, lat long pair to a standard format (example - lat long pair) according to what the weather data provider accepts in the API request.

(iii) How will data querying, cache updation and anomaly detection work?

--> Data querying service can query weather data on demand and in a scheduled way (which will be done by a cron job), which will be done at intervals equal to the granularity of the weather provider's data.

--> This weather updates will be posted to the message queue / event processing system like Apache Kafka, Apache Spark, etc.

--> Data aggregation service can be something like Apache Hadoop map reduce framework to take the data and compile it into lesser granularity if we need.

--> Weather anomaly detection will process the events in the message queue and check it against certain predefined rules stored in DB or file system and if some anomaly is found, this service will query the PGSQL DB to get the user details for sending notifications.

(iv) Consistent hashing, distributed servers in the microservices, multiple data centers, regions, etc. - these are some techniques which will be used for scalability and availability.

(v) Handling vendor outages - For transient faults, we can use retry mechanism to retry the request in specific time intervals. If no. of failed requests exceed the threshold then we can consider that as a service outage and in this case we can do 2 things (i) we can have a plan B vendor where we can route the requests while the main vendor is down (ii) circuit breaker pattern - we can do circuit breaker design pattern and show some message like "Weather data currently unavailable" or we can show the last cached data till the vendor service is back up.