System requirements

Functional:

• Users expect real-time responses from the service
• Users fetch weather information and supply a location

Non-Functional:

• There is a rate limit on the external Weather API
• Service has to scale to the number of users
• No need to persist user information and users can access the service without authentication

Capacity estimation

Estimate the scale of the system you are going to design...

• We expect 10k users interacting with the systems maybe simultaneously
• We will rate limit the service to 1000 requests per hour per user
• If we have 10k users who can send max of 1000 requests per hour, we'll expect an upper bound of 10 million requests per hour.

API design

Given that we are leveraging an external API, having Rest calls for typical requests alongside sockets or SDKs like Firebase that are available for emergency notifications would be ideal.

The primary API call would be the following REST API endpoing

GET /batch-weather

{

locations : [

{

city: ""

country: ""

},

]

}

This endpoint can be used to obtain data for a series of locations depending on how many places a user has subscribed to.

A secondary endpoint can be used to retrieve weather for a specific location that a user is looking up, or for the user's direct current location.

GET /weather?long=""&lat=""

This one will be specifically given details from whatever location a user is attempting to search up directly.

Database design

The client will

High-level design

We are going to have to have a design where a client would first hit Rate limiter and then the load balancer which would redirect our request to the weather retrival service.

It will first check the content in the Redis Cache. If it exists, it will return the results in the content.

Otherwise, it will send the request to the message queue to get the response from the external weather API.

Request flows

For the end to end flow, a user will make an unauthenticated HTTPS request to the service. They'll send along their longitude and latitude coordinates in the GET request. A stateless server will accept the request and make a read-through request to Redis. If there is fresh information in the cache. If there's a data point in the cache that is within the acceptable range of a user's location, then we will return the data to the server. The server can then return this data directly to the user.

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

Our reliance on the external API is a single point of failure. If the external API goes down, our service goes down as well.

The user request volume is a potential bottleneck as well if there's a burst of traffic that our servers won't be able to handle.

Future improvements

If we hit the weather API rate limit, we can consider serving users weather information close to location they requested. For example, we can consider a radius of 1 mile from the requested location as information that's accurate enough and serve that information to users. We can also consider leveraging multiple weather providers so we have fallback options in case one fails.

We can leverage DNS routing to route users to their closest geographical weather service. This will help alleviate the user request volume. We can consider replicating more services in dense, metropolitan areas to accommodate for areas that might experience higher volume of requests.

We will integrate the service with logging capabilities so we are able to alert on server and general region unavailability.