System requirements

• User can retrieve weather information when they give the name of city by searching
• User can add a city to their watch list
• We need to have a weather system to record information about weather in one specific location
• Prediction data
• [P2] Weather tips
• 
  

Non-Functional:

• availability
• latency - real time data

Capacity estimation

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

• Geo location precision to cities ~ 10k
• Every weather data has a 30days weather window
• User assume is 1M
• QPS is around 500
• for each city, we store real time temperature as well as 30 days predictions, assume 1 city requires 1kb
• 10kb * 10k = 100kb * 1k = 1mb data storage
• 
  

API design

Define what APIs are expected from the system...

For user

• @get /realTimeWeather
• Req
• cityID: string
• Res
• weather
• temperature
• summary
• @get /futureWeather
• Req
• cityID: string
• days: int
• Res
• weathers[]
• temperature
• summary
• 
  
• @get /search
• Req
• keyword: string
• Res
• cities
• id: string
• name: stringf

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

• City
• id @id
• name @indexing
• country

• Weather
• uuid @id
• temperature
• overral
• RealtimeWeather
• cityID
• weatherID
• @@id(cityID, weatherID, timestamp)
• WeatherPrediction
• cityID
• weatherID
• date
• @@id (cityID, weatherID, date)

High-level design

Components

• Client
• API gateway
• Read Server
• Write Server
• Database

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

• Weather injection service
• every second we proactively call 3rd party api to retrieve latest weather information and write to db
• we can circly retrieve all cities
• For cities search, we may want to support 2 types of search
• 1. by text search
• we can firstly prepare a full list of major cities in the world and store them as City in our database
• we index the city name, alias for text search
• we also need to retrieeve/store city's geo inforamtion for further serach
• 2. by geo coordinate search (using geo location and retrieve my place)
• we can use google s2 to find the nearest "city" in our data base and return it to use
• 
  

Trade offs/Tech choices

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

• Store watchlist on BE or FE
• BE
• Pros
• 
  
• Cons
• FE
• Pros
• No backend needed, no schema, no ai
• Fast fetching
• Fast development
• Cons
• Need to use local storage, so it's tight to device, not "user"
• User change device will not have this wachlist information
• NoSQL, not SQL
• we need to support frequent writing
• data consistency is not important
• also because the locations are limited (we only consider majior cities in the world) we can use cache like redis to accelarite our service (because we won't requires a lot of storage)
• we need cache to be persistent so redis, not memcache
• We can improve the performance by shardinng our db by their geo locaiton

Failure scenarios/bottlenecks

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

• weather API service is down
• Solution: we can retrieve data from multiple resources
• since our application requires high availability, we can horizontally create replicas

Future improvements

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

• proactively send data to users