0

We currently have a monolithic code base which we are in the process of extracting some micro-services where it's obvious to do so.

One thing that stands out is our email delivery. We have numerous points in the code base where emails are created and are sent out via a number of different templates. What I want to do is take this load and move it to a queuing system. Going forward the user facing web app would simply send a message to the queue stating for example a project has been won.

So what I'm trying to work out is where the data for the email (which can be a fair amount at times) should come from. Should we be packaging that data up with the message or should the queue handler be looking at the type of email that needs to be sent and then going and getting that information at that point.

1
  • 2
    We can't tell you this. If you have only two e-mails that you send, it's clearly right to specify the type. If every e-mail is completely unique, it's clearly right to put it in the message. If you're somewhere inbetween, you need to make that decision. – Philip Kendall May 14 '20 at 17:21
2

Making the queue handler look at the type of the e-mail would make the microservice very domain specific. There are a few cases where this makes sense, but in general, you may want your microservices to be much more generic.

How to find if you need it to be specific or generic?

  • List the usages of the service. YAGNI; don't think necessarily about the usage two years in the future, but how you will use the service right now.

    It might be that, like Philip Kendall said in his comment above, there are just two types of e-mails that you send. In this case, I'll question the choice of a separate microservice, but if separate it would be, a domain specific microservice would make sense.

    Or you may be sending e-mails from multiple other services, each one having its own quirks, and you know that right now, there are other services being developed, and other types of e-mails being designed. In that case, design a generic microservice.

  • Think about the name of the service. If something such as “simple notification service” comes into mind, you may have a good sign that the service should be generic. If you're thinking more about “Winning project notification service,” then go for a specific one.

  • Imagine what would happen if you need to change a type or add one. Would you need to change only one service? Or you will have to modify two (or more) services side by side, and deploy them together? In this second case, you are doing it wrong: instead of a microservices architecture, you are just adding REST calls to a monolith.

By the way, check Amazon's SNS for inspiration. It may give you opportunity to see how Amazon designed a thing which may be similar to yours. Their microservice is also a many-to-many queue system, and is actually cleverly designed. One of the interesting things is that the consumer of SNS doesn't need to know whether the notification would lead to an e-mail, or a push notification, or an SMS—this is handled within the SNS configuration itself. This way, you get an ideal microservice which does one and one only thing: dispatching notifications.

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.