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:

• Availability: The system should be highly available.
• Reliability
  1. The System should behave correctly and deliver the functional requirement even in case of failure, request spikes and other outage.
• Scalable: System should be highly Scalable for 100M users and be able to tolerate request spikes.
• Latency: The Read and write request should have very low latency.

API Design

• Weather Lookup
  • HTTP GET: /api/v1/weather?lang=&lati=
  • HTTP GET: /api/v1/weather?city=
  • HTTP GET: /api/v1/weather?lang=&lati=&timeunit=hours/days&timevalue=1
  • HTTP GET: /api/v1/weather?city=&timeunit=hours/days&timevalue=1

Response: ["date":"", "hour":"", "weather":{

"temperature":"",

"humidity":"",

"wind":"",

"precipitation":"",

"city":"",

"description":"",

"weather_type":"SUNNEY/COLUDY/RANING/COLD"

"icon":""

}]

• Subscribe/unsubscribe for notification/notification
  • HTTP PATCH: /api/v1/weather/subscribe/{email}/{flag}/{messageType}

Path Parameter:

email: User Email

flag: SUBSCRIBE/UNSUBSCRIBE

messageType: email/sms/push

• Resolve the City Name by GeoLocation
  • HTTP GET: /api/v1/geolocation/{long}/{lat}/

Path Parameter:

Longitude

latitude

Response: name of the city/place

High-Level Design

1. The User Sends a request to get the weather details.
2. The request First hit the CDN and checks for the weather data available in the cache. If it found in the CDN cache then it respond to the client from there. CDN holds the GeoLocation data of forecast/historical data upto 7 days
3. If weather data is not found in the CDN the it hit the API Gateway through which it hit the Weather Service.
4. Weather service first check on the cache if request weather data is available and returns the data if found in cache else it lookup the data into database.
5. batch Processor service has scheduler which executes the batch job every 5 minutes and refresh the cache which is available for refresh. and the data is updated in the cache.
6. Alert service is responsible to sent an alert to subscribe customer. It also has a scheduled job which trigger after a specific interval. it lookup for the customer who is subscribe for notification.
7. Cache Layer: The weather data will be maintain in the cache, where key will be the longitude and latitude and value will be the weather data. The Hot data which is current weather will have a TTL time as 15 minutes, a Week forecast data will be a warm data which has a TTL time as 1 days.
8. The Historical data will be persisted into the Object Storage.

Detailed Component Design

1. Client:
   1. Client can be the Web/Mobile application user.
   2. Client can be the third party Users who are using a APIs.
2. CDN
   1. The Request First get into CDN which are located to the nearer to the User.
   2. The Weather Data check if its available within the CDN cache and return from there this help to reduce the latency and respond to the user within 10-20ms.
   3. The CND cache TTL will be short upto 15 minutes for the current weather data upto 24 hrs. for the Forecast weather data it will be 1 day.
3. API Gateway
   1. API gateway hits if the data not found on the CDN.
   2. It has a load balancing feature to forward the request to the appropriate instance of weather service.
   3. it also has a rate limiting such as individual user can send 60 request per hour and third party application user can send 600 request per hours upto the subscription they have purchase.
4. Cache
   1. It caches the Hot (current weather data) and Warm (forecast weather data) data.
   2. The Data Key will be the longitude and latitude along with the weather data.
   3. if user search with the City name then to get the longitude and latitude of the given city it also cache the data where city will be the key and its longitude and latitude will be the value. this data will have a TTL time as 1-2 days.
   4. Current weather data upto 24 hours will have a TTL as every 15 minutes and forecast data upto 7 days will have a TTL as 1 day.
5. Weather Service
   1. Weather Service is responsible to process a user weather forecast request.
   2. It first lookup for the data in the cache and as a fallback it lookup into the database.
   3. User can also Subscribe and Unsubscribe notification using the APIs from this service.
   4. This service is highly scalable horizontally so that it can process a heavy traffic mostly during the specific time window of the day.
6. Batch Service
   1. Batch Service will have a scheduler.
   2. The Scheduled job is responsible to refresh the weather data after every specific interval.
   3. it also publish an event to the notification service to sent an alert to the subscribe user.
   4. To Refresh the weather data there will be the multiple vender APIs which will be access through the batch jobs to get the updated weather data for refresh activity.
   5. There are 2 types of vendor pull based and push based. As mentioned in the point-6 batch service application access the vendor APIs to pull the fresh weather data.
   6. In the push based approach Vendor publish the event if there is any update in the weather data.
   7. If any of the vendor down or not serving a request then through the circuit breaker application can try for the secondary vendor service.
   8. The weather data will be store with the longitude, latitude, hour so that it cant be duplicated.
7. Alert/Notification Service
   1. This service is responsible to subscribe to the topic and get the events send by the batch service.
   2. It Sends the notification to user based on the subscribe channel by the user.