Notification Service in microservices architecture

user_1583944 0
Viewed 3778

We have a microservices architecture to support a big application. All the services communicate using azure service bus as a medium. Currently, we are sending the notifications(immediate/scheduled) from different services on per need basis. Here comes the need for a separate notifications service that could take that load and responsibility of formatting and sending notifications(email, text etc).

What I have thought: Notification service will have its own database which will have data related to notifications(setup, templates, schedules etc) and also some master data(copied from other sources). I don't want to copy all the transactional data to this DB(for abvious reasons) but we might need transactional and historic data to form a notification. I am planning to subscribe to service bus events (published by other services) and onus of sending the data needed for formatting the notification will be on service raising the service bus event. Notification service will rely on that data to fill up the template(stored in ots own DB) and then send the notification. Job of notifications service will be to listen to service bus events and then fill up the template from data in event and then send the notification.

Questions:

  1. What if the data received by notification service from service bus event does not have all necessary data needed in notification template. How do I query/get the missing data from other service.?
  2. Suppose a service publishes 100 events for a single operation and we need to send single notification that that whole operation. How does the notification service manage that since it will get 100 different messages separately.?
  3. Since the notification trigger depends on data sent from other sources(service bus event), what happens when we have a notification which is scheduled(lets say 6am everyday). How do we get the data needed for notification(since data is not there in notification DB)?

I am looking for some experience advice and some material to refer. Thanks in advance.

microservices push-notification azure notifications
2 Answers

  1. You might have to implement a notification as a service which means, imagine you are exporting your application as a plugin in Azure itself. few points here.....

    1. your notification will only accept when it is valid information,
    2. Have a caching system both front end(State management) and backend, microservices(Redis or any caching system)

  2. Capture EventId on each operation, it's a good practice we track the complex operation of our application in this way you can solve duplicate notification, take care that if possible avoid such type of notifications to the user, or try to send one notification convening a group of notifications in one message,

3.Put a circuit breaker logic here to handle your invalid notification, put this type of notification in the retry queue of 30mins maybe? and republish the event again

References

Happy coding :)

user_99119690

In microservice and domain driven design it's sometimes hard to work out when to start splitting services. Having each service be responsible for construction and sending its own notifications is perfectly valid.

It is when there is a need to have additional decisions be made, that are not related to the 'origin' service, where things become more tricky.

EG. 1

You have an order microservice that sends an email to the sales team and the user when an order is placed.

Then the payment service updates sales and the user with an sms message when the payment is processed.

You could then decide you and the user to manage their notification preferences. They can now decide if they want sms / email / push message, and which messages they would like to receive.

We now have a problem. These notification prefrences would need to be understood by every service sending messages. Any new team or service that starts sending messages needs to also remember to implement these preferences.

You may also want the user to view all historic messages they have been sent. Again you get into a problem where there is no single source for that information.

EG 2

We now have notification service, it is listening for order created, order updated, order completed events and payment processed events.

It is listing for: Order Created Order Updated

Only to make sure it has the information it needs to construct the messages. It is common and in a lot of requirements to have system wide redundancy of data when using microservices. You need to imagine that each service is an island, so while it feels wasteful to store that information again, if it is required that service to perform is work then it is valid.

Note: don't store the data wholesale, store only what is relevant for that service.

We can then use the:

Order Complete Payment Processed

events as triggers to actually start constructing and sending the messages.

Problems:

  1. Understanding if the service has all the required data

This is up to the service to determine. If the Order Complete event comes through, but it has not yet received an order created event, then the service should store the order complete event and try to process again in the future when all the information is available.

  1. 100 events resulting in a notification

Data aggregation is also an important microservice concept, and there are many ways to ensure completeness that will come down to your specific use case.

user_5940150
Related