Design architecture of a notification system

Question

I need to design a notification system that will send notifications to users when events happen.

I have a microsystem environment, actually, when an event happen, a ms sends a message in a queue (q.send-event), that will be consumed by a notifications microservice. The listener of q.send-event queue, actually, makes a REST call to users microservice, to gather the list of all users that will receive the notification. After the user's list is gathered, then it store the notifications in a database.

I feel that this approach is not so scalable, can you suggest me a more efficient approach? Thanks

Answer 1

The listener of q.send-event queue, actually, makes a REST call to users microservice, to gather the list of all users that will receive the notification.

In microservices architecture synchronous calls between services in general case are considered to be not the best option. In this case I think the standard approach with data duplication is a way to go:

notifications maintains a readonly copy of user data (only the relevant one) which is asynchronously updated via message broker (i.e. every updated of data in user service produces corresponding message which is consumed by subscribers one of which is notifications which saves only the needed data to it's own storage). This removes the necessity of calling users during processing of q.send-event.

As an extension of this you can migrate user notification settings to the notifications service completely (better done with moving the notification settings to separate part of the UI or managing this with BFF/API gateway approach). I would argue that from business logic/domain point of view notification service can be a natural owner of user notification settings (unless you want to introduce another service):

Note that actual "best" implementation can be heavily depended on the actual business requirements, data amounts and SLAs.