Loading...
The application will keep track of the following
The weather application could also provide forecasts for the up to 2 weeks in advance
You should be able to see the weather information for your current location as well as other specified locations
Your application could also potentially send notifications for natural disasters to people that are near the location
Your system should be available. Anyone, anywhere can request to view weather information at any time
System should be robust, as there might be hundreds of thousands of people requesting for weather information at any point of time
Your system should not be too slow when providing weather information, it can afford to have 1-3 seconds of latency
This application would be read heavy, lets say there are 5 million requests made per day.
What I am planning to do is to have our backend servers call common weather APIs (for example Google's geological APIs) for different locations every hour or so, the results will be stored in our database for access. Hence, lets say we are keeping track of 10,000 locations.
Storage estimations,
Traffic Estimates
request_weather(location, day=today)
send_alert(location, natural_disaster)
Because the majority the data that we have will be from API calls, we can actually keep all the information within memory of a particular server (105 MB only) we can use a memcache like Redis where our key-value pair could be
(location, day) -> (weather information json)
This allows for fast retrievals of information instead of going through a database
In terms of high level design,
our client will request weather information for a location and a particular day through an API call, the server will then look through the cache to retrieve the information and return it to the client. Occassionally, (every 30 min - 1 hour) the server will call a weather API to update the weather information different locations, we should ensure that the current weather information in our redis db is not more than 1 hour old. We can keep an array of locations and loop through the array occassionally calling the weather API for a particular location
When natural disasters occur, our system could call an API to retrieve telecommunication towers within the affected area, we can then call the send_alert API, which will then allow the telecommunication towers to blast the alert to all individuals within 20KM of the affected area.
our client will request weather information for a location and a particular day through an API call, the server will then look through the cache to retrieve the information and return it to the client. Occassionally, (every 30 min - 1 hour) the server will call a weather API to update the weather information different locations, we should ensure that the current weather information in our redis db is not more than 1 hour old. We can keep an array of locations and loop through the array occassionally calling the weather API for a particular location
Occassionally, our servers will send an API call (Google API) to check whether there is a natural disaster occurring. If there is, retrieve the information of the natural disaster (earthquake magnitute, tsunami warning, tornato warnings) our system would then call an API to retrieve telecommunication towers within the affected area, we can then call the send_alert API, which will then allow the telecommunication towers to blast the alert to all individuals within 20KM of the affected area.
We are expecting about 5 million requests a day, meaning we will most likely need a number of servers to meet read demands. Assuming a server can handle 20 requests per second, we would need at least 3 servers to handle this, however since we need our service to be available and robust, we should ensure that our system does not fail, this means having back up severs for each of the 3 servers. There could also be a server that is dedicated to updating the current weather information
Keeping the weather information within the memory of each server means that the servers could potentially have differing information regarding the current weather state of a particular location at any point of time.
However I believe that this better than keeping a centralised database as the total storage needed is less than 1GB, furthermore, writing and reading from a database can incur unnecessary overhead which could otherwise be solved when keeping the information in a memcache
A potential hazard could be a malicious user that can send many requests to our server and overload it
To mitigate the dangers above, we could possibly have an API_DEV key for each user, we could possibly implement a rate limiter that limits the amount of request a user can send based on the api_dev key
Another potential improvement is automatic location setting. We could ask users for permission to share their location with our application, then the user need not input the location to the API, the application would already know their current location and then fetch the current weather information for that particular location
At the moment, our system is only accurate every hour, however future improvements could want our system to provide real time updates on the weather.