Who should handle sending emails in microservice architecture if as a email sending using APIs like Sendgrid, Mandrill and etc?
- each microservice should send on their own, because it is just HTTP API (some of cons: each microservice should know email of each user in system, pros: easy to implement)
- another microservice should send emails based on events (some of cons: single point of failure, pros: emails would be known only by this microservice and changing email in profile would change only in one place)
Best Answer
As pointed out by Laiv in the comments, it's not a clear cut answer. A lot depends on where your priorities are.
A single central mailing service may be the cleanest and most "proper" in a microservice environment. It's certainly something I'd seriously consider.
But building a configurable email library to abstract the details of the mail service used and linking each microservice that needs to send email to that is another option that may well be viable (and is of course how things have been done for decades).
Advantage of the first option (beyond its architectural purity) is that you have only a single thing to change if something changes in the email environment. Disadvantage is that you have now introduced a single point of failure, if the mail service you built goes down for any reason, you can no longer send email at all from anywhere. Of course running multiple instances and load balancers to direct traffic between them can in part alleviate that risk, at the cost of higher complexity.
Second option has the distinct disadvantage that you need to rebuild and redeploy every single microservice if your email library changes.