System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

1. Provides users with current weather information for a specified location, information should be accurate and up to date.

Non-Functional:

List non-functional requirements for the system...

1. Scalability- should be scalable across global regions
2. Availability- should be highly available with minimal downtime
3. Reliability- information should be accurate and up to date
4. Security- user location data should be secure and encrypted
5. Performance- weather data should display under ~1 second for local area and under ~5 for non local areas

Capacity estimation

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

Assume ~200 requests a second to check weather, need a system to handle that level of load, maybe ~50,000 regions each with up to 256 bytes of data, roughly 1 GB of data that will need to be updated regularly

API design

Define what APIs are expected from the system...

• getWeatherData(location_ID) - gets weather data for the given location corresponding to the location_ID from the internal database, this could be triggered by the user changing locations if location permissions are given
• updateWeatherData(location_ID)- updates weather when database information is out of date

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...

Since the National Weather Service maintains a database of weather information that is up to date a version of this app could be made without using a database since the user only needs current weather.

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

Components-

• Load balancer- distributes incoming client requests evenly and implements auto-scaling groups
• Application Gateway creates a uniform entry point for client requests that can handle security, route to multiple services, and handle rate limiting
• Get Weather Data Service - a service that handles retrieving weather data and returning it to the client
• Update Weather Data Service- a service that handles retrieving weather data from external services and updating the database
• Cache- a caching service like Redis or Elasticache to cache frequently accessed data
• Content Delivery network- a node where local weather data can be stored near users who need to access it

Key Interactions

• Load balancer distributes request evenly across API Gateways and handles auto-scaling
• API Gateway routes requests checking the cache and if failing updating cache from external sources then returns information to client
• Content Delivery Network- returns data to user from an edge location
• cache- stores frequently accessed data from an external source and returns data to user if it is valid
• Get Weather Service - checks cache for requested data and calls Update Weather Service if not found
• Update Weather Service- updates cache from external sources and has cache return weather data to user

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...

• API Gateway
  • Scalability- and API Gateway placed behind a Load Balancer in an auto-scaling group ensures high scalability, reliability, and performance. Scaling out and in horizontally as needed
  • Data Structure- simple routing table passes call to Get Weather Data Service, only service right now but makes it easy to add additional services if this becomes necessary
  • Security- handles basic security layers like authorization, rate limiting, and input validation
• Cache
  • Scalability- Elasticache would probably be the best choice because of it's high scalability, reliably, and performance which this app necessitates with it's high read/write demands
  • Simple eviction Algorithm to evict out of date data i.e. time based. Probably using a queue to evict data and a hash map to store weather data for quick access

Trade offs/Tech choices

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

• A content delivery network has an added cost but this increases the available user base to a global scale
• Elasticache was used instead of Redis or something similiar that would be self managed because this allows for better scalability/availability. In addition the serverless architecture means less overhead
• ALB in combination with API gateway ensures high availability, scalability, and performance. In addition an API Gateway is used instead of just direct service invocation because an API gateway handles rate limiting and authentication, in addition if more services are added you can easily maintain centralized control over incoming requests reducing cross-cutting concerns like authentication and rate limiting
• Since the request was only for current weather information I opted for using only a cache and using external weather databases (like the National Weather Service which provides free access to weather data), this puts reliability on an external service but significantly reduces overhead and cost and availability gaps can be filled by a Content Delivery Network like CloudFront with a caching service like Elasticache

Failure scenarios/bottlenecks

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

Possible failure scenarios:

• If load balancing and auto scaling are not properly implemented the API gateway represents a single point of failure
• To avoid service overload or lack of coverage from service crash has the services in instances that horizontally scale and have health checks done regularly taking down and replacing unhealthy instances, the same is true for the cache and API Gateway

Bottlenecks

• A lot of the bottle necks are also solved with horizontal auto scaling and health checks i.e. API gateway, Service Overload, cache capacity
• A CDN helps reduce average network latency globally

Future improvements

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

An notification system could be added to notify users of approaching storms or other inclement weather, this could be implemented with something like AWS SNS, this increases the interactivity of the app and increases user engagement.

In addition an internal database would allow user to save favorite locations and receive notifications for multiple regions, this again would increase user engagement and app interactivity by allowing people to see current weather were friends and family may live away from them.

Localization and Internalization

• Improvement- support multiple languages and local texts and optimize performance for various geographical regions
• Benefit- makes the service more accessible to a global audience and improves user experience across different regions

1. Machine Learning for Traffic Prediction
   • Improvement- use machine learning to predict traffic bursts and intelligently manage resources
   • Benefit- efficient allocation of system resources based on predictive models can reduce costs and improve service availability under unexpected loads