Detailed Component Design

fresh data is achieved using the various caching along the way:

CDN - to keep highly requested data cached for a short duration to reduce both latency and load, with a short TTL of 15 minutes for current weather, and a long 3 hour TTL for forecasts.
cache for geocoding mapping, current weather and forecasts. it is also achieved by keeping data in out dedicated DB to prevent calling the weather provider multiple time upon each request.

another aspect to keep the data fresh is using the weather updater CRON jobs - we can using multiple of these to query the weather provider and scale them to update horizontally(instead of having a few that are in charge of multiple regions, each could be in charge of smaller areas).

the various services - subscription, weather service and weather updater can all be scaled up or down depending on CPU usage to fit an increasing or decreasing amount of users. so in the case of increased usage like a storm or hurricane, where people check the data a lot servers can scale.

we have a single weather provider which is a single point of failure - we can introduce more providers and use an adapter pattern to spread the load among multiple providers to not relay on a single provider.

we can also add circuit breakers in front of each provider to allow them to recover gracefully and meanwhile relay on information in the cache and DB - a bit stale but we don't want to keep a provider down. when a provider is down we trip after 5 consecutive failures within 30 seconds and return cached data for 60 seconds, implementing a half-open probe after 30 seconds to check if the vendor is back online. meanwhile we try a different vendor if possible, otherwise we relay on data in cache and DB. the communication with vendor/s return once a health check is performed and they function properly.

the system is read heavy and the users expect fresh accessible data:

so we can introduce redundancy for the cache in case of failure. if it fails data is queried from the DB, which impact latency but still works, and worst case scenario of DB failure we can batch requests and query the weather provider directly.
DB should sharded based on a regional shard key - most people want to know weather for their area, so we can separate based on location meaning the id of lat,long using PostGIS for location data. to make the data highly available we'll also introduce secondary database, and backup snapshots(every hour) in order to avoid overwhelming the weather provider in a case of failure. and between snapshots keep logs of updated data the update the DB from the updates from the logs.
streams should also be partitioned based on a partition key is the shard key of the DB, again since users want data in their proximity.

so data is highly available - in a CDN for frequent API responses, cache for sessions, geocoding mappings, current weather and forecasts, DB with geospatial indexes.

the data is eventually consistent using a request miss(not in cache or DB) which makes the weather service query the weather provider. stale data is viewed for a grace period of 10 or 15 minutes before updating again from the DB that should be updated.

in a case where a weather provider request fails or sending a notification fails we perform retries with timeouts with exponential backoff with jitter. the worst case here is slightly stale data but for being highly available its a relatively graceful solution.

the data that is inserted to the DB should be idempotent based on the location and timestamp. if any requested data is received and fresh data is already exists it is discarded since its not needed any more. duplicated data for the same request are also discarded. that way the information remains fresh.

another possible improvement is to separate the DB to 2 DBs - a relational DB(Postgres) for user data and subscription. and a NoSQL DB(Cassandra) for the weather data and forecasts to handle growth of data entries. each entry is roughly 100 bytes(id, lat, long, temp, humidity, wind speed, etc., timestamp), lets say there are roughly 30K relevant locations and we update a locations data at least 4 times an hour - thats roughly 0.5Gb per day. and we do the same for a weeks forecast so another 3Gb. that's 3.5 Gb data per day, which is roughly 1.5Tb per year. so we'll move only the raw responses from the weather provider to a NoSQL DB that can also handle high traffic and support scaling effectively.

the relational DB can easily handle the data that remains there - subscriptions to events (user id, lat, long, status, createdAt, updatedAt - roughly 200b) and user info(roughly 500b) and mappings (lat,long, name - roughly 200b) - data that changes infrequently - 5 * 100M* 200b + 500 * 100M + 60K locations * 200b, which is roughly 2Tb.

request coalescing will happen in the weather service, when receiving a multiple of similar requests based on the location it would prioritize handling those using a single flight request to the cache, DB, provider and answer all of them.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10