Loading...
2) User should be able to see the weather for next 7 days or last 7 days
3) User should be able to see real time weather.
4). Weather should be as accurate as possible
5) User should be able to add notifications for the weather changes and their duration.
List non-functional requirements for the system...
1) System should be highly available
2) System should be tolorent to network partiion
3) System should serve request with minimum latency
4) Sysetm should be highly scalable
}
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...
Each User makes a call to weather Service to get the weather details each call will be made to api gateway which then will call the service each api gateway will have the logicc for rate limiting and authentication then call is made to weather service which checks whether
theer is entry for the weather with the filter conditions if it si there it is serverd from cache else the call is made to db to get the required ata as the weather service is stateless we can easily sclare those we can scale the database by following master slave architegbure
similary the cache can be scale using the same we can handle the failure using exponential backoff and to prevent thundering hurd problem we can introduce a jitter this take care fot he seruvce
For Collection service we will use pull instead of push as the connection to the sensor will not be short lived and last for ever so using pull we will be able to monitor server health easliy we will have a sernsor api which will get the results fromt ehs sernsors and write it to
kafka partition by city or region and will have a flink to consume these events ususally the tempare are shown for different hours so we will use tumbling windows of one hour aggregate the data and store in our weather database it will be. a timeseries dtabase as entry will not be
much as we are agregating and reads can be served easily flink supports checkpointing to handle the failure and it can replay from the last checkpoint to hande out of ourder envents we can use watermarks and we will store each our entry in our database we will use cdc beteween
databse adn debezuim to ensure the redis and debezimum are up to date
For notification service we will support different types of notifications like apns, fcm an. email service for user t0 set up costom notification added message queu in front of notificatin servei to make it fault tolorent.
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...
Each User makes a call to weather Service to get the weather details each call will be made to api gateway which then will call the service each api gateway will have the logicc for rate limiting and authentication then call is made to weather service which checks whether
theer is entry for the weather with the filter conditions if it si there it is serverd from cache else the call is made to db to get the required ata as the weather service is stateless we can easily sclare those we can scale the database by following master slave architegbure
similary the cache can be scale using the same we can handle the failure using exponential backoff and to prevent thundering hurd problem we can introduce a jitter this take care fot he seruvce
For Collection service we will use pull instead of push as the connection to the sensor will not be short lived and last for ever so using pull we will be able to monitor server health easliy we will have a sernsor api which will get the results fromt ehs sernsors and write it to
kafka partition by city or region and will have a flink to consume these events ususally the tempare are shown for different hours so we will use tumbling windows of one hour aggregate the data and store in our weather database it will be. a timeseries dtabase as entry will not be
much as we are agregating and reads can be served easily flink supports checkpointing to handle the failure and it can replay from the last checkpoint to hande out of ourder envents we can use watermarks and we will store each our entry in our database we will use cdc beteween
databse adn debezuim to ensure the redis and debezimum are up to date
For notification service we will support different types of notifications like apns, fcm an. email service for user t0 set up costom notification added message queu in front of notificatin servei to make it fault tolorent.
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...