System requirements

Functional:

A user should be able to:

• Request a weather forecast for a specific location
• Create a weather alert or forecast notification for a specific location

Non-Functional:

System should:

• be available for user most of the time
• timely notify users based on their alerts configuration
• be eventually consistent

Capacity estimation

Let's assume:

• 1M user base
• 1k rps

Based on the assumptions above, we'll need:

• approximately 512B per user (unique id, email and creation time), so 5 * 10^2 * 10^8 = 50GB of user storage capacity
• say, 2 alerts per user, each alert contains only a unique id, geolocation id and creation time ~ 50B * 2 * 10^6 = 100MB of storage for alerts

API design

A user would like to:

1) be able to request a weather forecast for a specific location on a specific date

GET v1/weather// - returns a requested forecast

200 OK

{

location,

date,

temperature,

precipitations,

...

}

2) subscribe to weather forecasts for a specific location (and weather alerts)

POST v1/users//subscriptions - it will take a request parameters

{

location_id,

time

}

create a subscription and return a status code and a subscription id

200 OK

{

user_id,

location_id,

subscription_id,

time

}

3) remove a user's subscription

DELETE v1/users//subscriptions - it takes some additional data and removes the subscription

{

user_id,

subscription_id,

time

}

4) list all their subscriptions

GET v1/users//subscriptions - returns a list of a user's subscriptions (with pagination)

{

[

{

subscription_id,

location_id

},

...

]

count,

offset,

total

}

Database design

We won't focusing on a storage for user accounts and only describe the one for subscriptions:

• most of the requests are expected to be for reading weather data
• we will need to find all the subscriptions by a user id and vice versa

Both of those concerns can be satisfied with a use of a relational DB with read replicas for read-scalability.

So, we'll store the following entities:

User

{

user_id: String,

}

Subscription

{

user_id: String,

location_id: String

}

And the forecasts themselves can either be stored in the same relational DB or in an key-value store, depending on requirements on updating those data.

Forecast Data

{

location_id,

}

High-level design

We going to have four main components in the system:

• Forecasts service responsible for providing forecasts to users
• it's a stateless service dispatching forecast request
• Forecasts updater service responsible for updating forecast information and triggering subscriptions notifications
• it's an offline batch processing service, interacting with a 3rd party agents
• Subscriptions service managing user subscriptions
• Notification service responsible for handling forecast data updates and notifying users according to their existing subscriptions

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

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

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?