How to Architect Notification Service Logic

Architecturebackenddesigndesign-patternsmicroservices

We are building a notification service whose work is to send push notification to end user. There are two types of notifications

  1. Group notification where we send same text notification to all user's in a group. This is easily achievable as everyone subscribe to a group and we send a notification to a group.

  2. Personalised notification where we send specific text notification to each user.

My question is (for Personalised notification) how best should we architect our notification service.

Approach 1: Do we keep logic of selecting users based on app logic on application service where we create message for each user and then send batches of users with message to notification service to send them?

Select Users based on application logic (on app server) -> Loop over each user and make their custom message (on app server) -> Make batches of 1K users with message and send to notification service (on app server) -> Send notification (Notification service)

  • Adds load on application server

Approach 2: we let notification service directly access app database and fetch users, create their message and send them?

Select users -> Loop over to make message -> Send to each user (All on notification service)

  • In this approach, notification service need to access app DB and lot of app logic go here, seems not right. As it will make notification service contains lot of app logic.
  • Take load off app server as everything needs to be done by notification service.

What do you guys suggest? Is there any other approach we can consider.
Considering we might need to send personalised notification to million users.

Best Answer

I think the answer to your question is how to identify service boundaries. Basic approach is that any service should possess all the data that is necessary for it to carry out its job. So services are defined not by horizontal layers, as it was the case in some SOA guidelines, but rather by vertical slices. It's some concrete piece of business-functionality or a business-process, with its own controllers, domain logic, and ui. It should be autonomous, so it doesn't need any other service's data or behavior.

So considering your example, chances are that your notification service should be a part of some bigger logical service. For example, if your domain is about some retail network, and one day there is some huge discount, and you want to notify all your customers. You need to have your customer's phone number, information about discount (probably tailored to particular type of customer) and a notification text. Who manages discount business rules? Which service owns customers' data? I bet it's a Sales service. So notification service is definitely a part of it. So this sales service should have its own database with all data need to send a notification.

If you're pondering on performance issues, it's okay to extract this notification functionality in its own physical machine, and in case of need just add some more machines. And there is no need to create a separate database for this newly extracted piece of functionality, since service boundaries are logical, not physical.

Here is a series of posts addressing these issues in greater details.

Related Topic