System requirements

Functional:

• Give weather information to users based on a specified location
  • Temperature
  • Sunny/rainy/cloudy
  • Evolution over the day
    • Morning
    • Afternoon evening
  • Forecast for next days

Non-Functional:

• The system should be highly available

Capacity estimation

• 500K daily active users
• Users checks the weather 3x a day on average
• 1.5M daily requests
• About 17 requests by seconds for 24hrs

API design

GET /forecast

input params: location, datetime

returns:

{

temperature,

condition

}

Database design

Forecast table

• Location COORDINATES
• Timestamp DATETIME
• Temperature DECIMAL
• Condition ENUM

The location and eventually the timestamp should be indexed to maximize lookup performance

High-level design

Two main services:

• Location service is an externaly provided service than translate a location name (like a city name) into coordinates (latitude, longitude)
• Forecast service is our service than answer the forecast queries

Request flows

• First the user entered location is translated by the location service if needed (if the user has entered a city name or something like this, otherwise we can use the location of the device)
• The user then sends its request to the forecast service
• The forecast service check if the data is in the cache
  • If yes it immediately returns the data
  • If no it fetches the data from the database

Detailed component design

We need to answer the user even if the exact requested location isn't in the database. To do that we can give the forecast of the closest location.

Efficient geospatial data structure (quadtree for instance) is needed to do that.

We should use a database system that supports geospatial data structure

Data can be cached using a TTL that trigger eviction when the period of the forecast is passed

Trade offs/Tech choices

As the system read-only (from a user perspective), there is no restriction regarding the consistency so we can choose the technology that provides us the best performance and scalability (NoSQL)

Failure scenarios/bottlenecks

There can be peaks of users activity like in the morning when users check for the current day forecast

To handle these peak of activity we can pre-cache the data for the next day during the night (only for the most frequently asked areas)

Future improvements

We will need an analytic service to know which areas are the most requested for our caching strategy