CODEWITHSUNDEEP
microservices
Rob
Rob

Reputation: 7216

Aggregated Notification Microservice

The Problem

We are currently architecting our new Notification Microservice but having trouble with how to handle aggregated emails. What we need to do is instead of sending one email every action performed (could be 20+ in a few minutes), we would send an email after an hour summarising all the actions that were completed.

What We Have So Far

We so far propose that we have this type of messaging pattern, where Client Service is any service in our cluster and Messagebot is our Notification Microservice.

  1. Client Service sends a notification to Messagebot that it will need to send something in the future
  2. Messagebot stores the details in its database
  3. Messagebot periodically checks its database for what needs to be sent
  4. Messagebot gets the required data from another service (could be Client Service) via API
  5. Messagebot sends email using the data from #3 and an HTML template

The Debate

For the data that needs to be sent, we are less sure and it is what we need help with. So far we think this should be the structure of the JSON from Client Service to Notification Service (step #1):

{
    template_id: SOME_TEMPLATE_ID,
    user_id: SOME_USER_ID,
    objectid: SOME_OBJECT_ID
}

or

{
    template_id: SOME_TEMPLATE_ID,
    user_id: SOME_USER_ID,
    required_objects: { task_id: SOME_TASK_ID, document_id: SOME_DOCUMENT_ID }
}

Where task_id and document_id are just examples and it would change based on the template. It could just as easily be {product_id: SOME_PRODUCT_ID} for a different template.

Why The Debate

Our thoughts so far are that:

  1. We only need template_id because the source of the data would be implied in the objects (like an ENV var). For example, the Task object would be at http://taskservice/:id. Otherwise, we can have problems with failing APIs or switching URLs in the future.
  2. We should use userid instead of email and name because we prevent the issue of email/ name pairs not matching up over multiple messages
  3. For the objects, we're still sceptical because it means that the client app service would need knowledge of the inner workings in Messagebot but a single objectid might not be very extensible. We could easily imagine many of our messages needing more than one object.

In Conclusion

Thank you for reading. The design of this service is important because it will be central to our entire organisation.

Which debated JSON structure is most appropriate in our situation? Also, knowing our requirements, what would be the proper setup for this type of service? (aka. Are we correct in our other assumptions?)

Upvotes: 2

Views: 2399

Answers (1)

Gang Gao
Gang Gao

Reputation: 1079

So your messagebot will

  1. store notifications
  2. get data from other services
  3. compile emails from the data and
  4. send the compiled emails

In my opinion, your messagebot were given too many tasks. If I were designing the system, I would like to keep the messagebot simpler. The servces should encapsulate the knowledge to compile the email, e.g. manage it's own template and so on. The services will push the compiled emails to a queue so the messagebot can pick up and send. The only logic in the messagebot is to pick up the emails from the queue and send. In this way, it doesn't matter how many more services you are going to have in the future, the messagebot will stay nice and simple.

Upvotes: 2

Related Questions