11

Sorry about my english - if some thing is not clear please ask me in comments - i will clarify this.

I build system in microservice architecture. I have one service with user information, one service for "offers", and one service for "ideas". Services "offers" and "ideas" comunicate (by Restful API) with "User" service on login and other operations. And i wonder - how to deal with emails? Each service have it separate frontend and send emails after some actions (eg. when some third person open link with some offer the user who create this offer will get email, or when some user create idea the manager will get email). Moreover, on each service frontend, manager can create "periodic" mailing with season statistical data or just some other information. Each service email looks differently and have different content.

I have many choices and don't know which will be better. This are some propositions:

  1. Each service has his own separate emailing system and send all kinds of email (after action, and periodic) independent.
  2. The "user service" have "engine" to send action and periodic emails and other services give the task. Inside task there is link to service who give task and that link will generate email content (for example witch statistical data in periodic email). This solution is complicated...
  3. The "user service" has only engine to periodic emails (tasks have link to generate email body...) but email after actions are send from each microservice indepenndent
  4. Create new microservice only for sending email (periodic and "after action") with proper API. Ofcourse each service like "offers" should send also link (to themself) in mailing task - this link will be call when the periodic email will be send and the response of this link will be generated body of email....

Which one will be better? Or may be there is some better alternative?

Kamil Kiełczewski
  • 85,173
  • 29
  • 368
  • 345

1 Answers1

5

Sending emails it's like making request to another service (via SMTP). So, that's a good approach when every service will be able to send emails.

But, of course there's some common logic for sending emails like rendering templates, sending code, configurations and so on. This logic should be shared between services via common code (dll, package and so on).

So, in this way:

  1. Every service doesn't depend on another service when it needs to send an email
  2. Common code for sending email is shared between services
  3. You don't have development, deployment and network overheads in the case of having dedicated email sending serviced

One drawback of this approach is that every service should have the same email configuration (SMTP address, login, password and so on). But if you share configurations between all services it's not a problem.

Leonardo Chaia
  • 2,755
  • 1
  • 17
  • 23
Vasyl Zvarydchuk
  • 3,789
  • 26
  • 37
  • 10
    Dosnt that kind of defeat the purpose of a micro-service? Having shared code between multiple services couples the services. The point of a micro-service seems to be to uncouple an applications logic. The more I think about it the more it feels like an anti-pattern. I think a much better way to "share code" would be through the use of a service that packs all that email logic you speak of inside it. That way youre sharing via a service not via a distributed library. – Verty00 Jun 16 '18 at 04:07
  • 2
    Verty, choosing how to share code via dlls or services depends on the task you perform. Every app uses a lot of shared code like framework libs, db connections and so on. In this particular case, I recommend this shared libs. But if you have a lot of logic related to sending emails it's better to create dedicated service for that. – Vasyl Zvarydchuk Jun 18 '18 at 16:07
  • 5
    "In short-term a reusable library speeds up the development, but it leads to coupling between the microservices. Consequently in long-term it slows down the development, increases the coordination effort and hinders modernization. The microservices are not independent any longer. Especially don’t use shared libraries for business logic and models. Instead, accept redundancy, introduce a shared service or reslice your microservices." https://blog.philipphauer.de/dont-share-libraries-among-microservices/ – Christopher Will Nov 22 '18 at 14:46
  • @Verty00 No, I dont think having shared library defeat the purpose of micro-services. ONLY if you need the library to stay always with the most recent released version. But if you can stick with old versions of the library, it's OK. As an alternative, you can have both - a microservice and a shared auxiliary library - like a smart client to send emails. This library could give the ability to send emails directly or using the email service. The library could even have the ability to fetch updated templates at runtime, so consumer services can send the email directly. – Juliano Jan 29 '22 at 13:31
  • The mail svc would be responsible to managing templates, controlling delivery (with a 1px img) and so on. – Juliano Jan 29 '22 at 13:38