Loading...
we're storing the user:
user_id: uuid 16 bytes
location_code: 16 bytes
alert_setting: 1 byte
around 10,000 writes a week
30 mega bytes a year
so totally within comfort zone of a relational db
Define what APIs are expected from the system...
create_user:
creates user
update_user_location:
updates user location (location is to know when to notify)
get_weather_data(user, location = none)
get data from weather provider with optional location to overwrite user's default location
notify_user:
when the weather provider api sends us an alert (web hook) for a location we query all users within location from the db, we check their alert_settings and then we can send notification to those users.
user_id -> uuid
location -> can be some standardized code (maybe zip code)
alert_setting -> enum of different settings of if/when to alert user
api gateway for authentication and rate limiting
for fetching, we have a distributed cache with short TTL because weather data is always changing.
for notification, we just pass the information to the user if they allow for it and are in affected areas (location)
user
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...
Explain any trade offs you have made and why you made certain
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?