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?