用于了解pub-sub消息是否成功的模式

Question

I'm developing microservices for a project and we're experimenting with pub-sub communication using AWS SNS+SQS. We're unsure how to signal to services whether or not other services have successfully completed tasks or not.
For example, if service A emits an SNS Event and service D, E, and F all are listening to the subscribed SQS Queue, how does service A know if the activities kicked off by service A inside of service D, E, and F were successful?

I'll give a more concrete example: A new user registers for a website. This network call first reaches the user service in the backend. If the user was successful, it sends off an event saying a new user was created. That triggers the email service to send an email to for the user to confirm his registration. What happens if it fails to send an email? Has the user service :

1) Already responded to the frontend saying it was successful

2) Or is it waiting for a confirmation? What is a good pub-sub pattern for confirmations?

I know we could have just done a synchronous call, but this example is simplified for brevity's sake.

Answer 1

As @dbugger says in the comments, you can have the subscribers send an ack or something back the publisher.

However, it is the publisher's responsibility to ensure the events were received by the subscribers?

Kind of the point of publishing events is that the publisher doesn't (and shouldn't) need to know about the state of consumers subscribing to the event, whether the subscribers ignored the message, or even if there are no subscribers.

If the publisher does need to know, then rather than an event, the publisher should be sending a command direct to the consumer in a request-response pattern, rather than an event.

This is because a command message assumes knowledge of the recipient whereas an event message assumes no knowledge.

In terms of knowing from a top-down perspective when an event has arrived: well, you should be using a durable message transport which can guarantee delivery of your event, but even with durability you can still drop messages.

The only real way of doing it is to implement some kind of instrumentation which allows you to track the "conversations" which are encoded in the events being published from place to place. There are tools available for this (I have only used one, for NServicebus called ServicePulse ).