Best approach for communicating between Emailing microservice and others

Question

I'm wondering what would be the best pattern for communicating with the Emailing microservice.

Let's assume that the first microservice (initiator) is responsible for managing users and therefore, among others, performs the following tasks:

• Registering user
• Updating user's email
• Resetting user's password

All of above require an email confirmation/password reset email to be sent to the provided email address, including some callback URL that would allow to confirm email/set a new password.

I see the following possibilities when it comes to notifying the Emailing service:

1. Publish/Subscribe pattern - initiator publishes events like UserRegisteredEvent to some messaging bus (eg. RabbitMQ) with an email and callback URL, Emailing service consumes that event and sends email. It seems like the least coupling way and most flexible as any other service could subscribe to these events if needed. But we lose a possibility to inform user when sending emails fails (kind of fire-and-forget).
2. Request/Response pattern - initiator sends request like SendEmailConfirmationRequest to some bus (eg. RabbitMQ) or remotely runs an action on the Emailing service (eg. gRPC) and basically waits for a response that could be a simple bool in this case. It gives more control and immediate information to the user if something fails.
3. Command pattern - basically same as the first, but commands would be called like SendEmailConfirmation and sent directly to the Emailing service.

Which one would you choose? How critical do you find getting a response out of the Emailing service in this particular case?

Answer 1

I would choose the command pattern as you are telling the email service (really a technical component (TC) and not a domain service) to do something.

The email service (TC) can then publish an event that the email was sent successfully and the originator can subscribe to that event and mark the action as complete.

Make sense?