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.

  • So you have a separate database for your application server? Why? And how do you differentiate what logic goes to application server, and what anywhere else? Dec 17, 2017 at 10:10
  • Application service has its own database and notification service has its own. Data with notification service is related to notifications only, no extra data. All application related data is with app database. Now my concern is if i keep all app logic for notification to app server then it might increase load on app server, so wanted to know how others do this. Dec 17, 2017 at 10:13

1 Answer 1


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.

  • Thanks for your reply. Seems like you are right. I should define my boundaries as separate so notification service should not do any business logic ( no app logic but only notification logic). I should keep my notification user's logic with app server for now and as it increases load i move it to separate service who's role is to find user's and then send to notification service. Approach 1 seems right and in future move that part to a separate service if needed. right? Dec 17, 2017 at 11:10
  • If notification service and an application service are part of one logical service, with a single database, I think it's fine. I just want to warn you against passing data between different services requiring synchronous communication. When not considering any performance issues, this usually means that your boundaries are wrong. And as I have almost no details of what your specifics are, I can not give you more concrete advice. Dec 17, 2017 at 11:29
  • 1
    In our case, both services has their own databases. I am thinking of making a List of NotificationObject(userId, message) which is passed to Notification service (notification service has token for userId) and notification service will send it to end user. Hope this seems fine as per SOA. No data sharing through databases that way we have separate responsibility. Dec 17, 2017 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.