As a part of changing our application from a giant monolith to a mic We are developing a Notification micro-service that can be used by all the other modules for sending notifications like Email, SMS , Push Notifications etc.
One client of this notification service is windows service that we are planning to develop , which triggers email notifications for various events like User Registration , Password Reset etc . The windows service will have a 2 parts
A REST based API that can be called by modules like User Registration to trigger the notifications. When the ReST API is called , this service will load the appropriate template , fill in the necessary values and call the notification service to send the email. In case the api call fails ,the details of the notifications shall be sent to a back ground task, which will retry the action for a fixed number of times before giving up and raising an error
The background task which will which will retry the action for a fixed number of times for sending the notification before giving up and raising an error
Our initial plan was to use a queue to communicate between the two parts. The flow will be like this
Client --> ReST API --> load Template and Fill Values -> Call Notification Service --> Add the message to Queue (In case Notification fails) --> back ground task pulls the message of the queue --> retries action --> Mark the notification as failed in case maximum retries have failed (which will be taken up manually
Instead of using a Queue, another approach is to use persistent AKKA.NET actors for doing this, since AKKA.NET supports Mail box but have not found any similiar use cases... Are we on the right path if we choose akka.net... Please sent ur comments
I think a queue is an appropriate abstraction for this - publish some messages to a queue and have the notification service consume them. If the notification service(s) is down, they stay on the queue until it comes back up. Something like Kafka might be a good fit for this, but you could probably implement something in whatever database you're currently using. I probably wouldn't go down the Actor route unless you have more complicated logic around things.