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 push instead of push as the connection to the sensor will not be short lived and last for ever so using push 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.
Caching will significalntly improve performance and make low latency
we are using push model for getting snesor data so no external api is being used and they will push when data is avaialble
As we are using flink we set rules on the system like if the ranfall is 100% in future then alert the user similarly if the humidity is more alert eh users.
We are using combination of read through and write aside for caching.
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 push instead of push as the connection to the sensor will not be short lived and last for ever so using push 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.
Caching will significalntly improve performance and make low latency
we are using push model for getting snesor data so no external api is being used and they will push when data is avaialble
As we are using flink we set rules on the system like if the ranfall is 100% in future then alert the user similarly if the humidity is more alert eh users.
We are using combination of read through and write aside for caching.
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...