2

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 summarizing 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 Microservce.

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 2) Messagebot periodically checks its database for what needs to be sent 3) Messagebot gets the required data from another service (could be Client Service) via api 4) 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 skeptical 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 organization.

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?)

1

I would propose the following separation of responsibilities:

  • MessageBot is reponsible for managing notifications to the user. It owns the logic for aggregating individual events into hourly emails. It also owns the logic for how particular events get put into some template.
  • The client simply reports events to the MessageBot as they happen. It doesn't know or care that an hourly email needs to be sent.

What does that say about your design?

  • The data from the client to the MessageBot should consist of single events (like your first option). They should be sent as the individual events happen.
  • However, both of your designs confuse configuration and event data. Template_ID should not be sent along with every event. Rather, logic like "these kinds of events should be sent to these users using this template" should be a configuration operation, which is set up once. The events themselves should not include any information on what the output looks like. Instead, they just need sufficient information on what type they are that the MessageBot can handle them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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