Micro Services - Entity Identity as a Dependency

In a micro-service architecture, we often need to communicate between services while keeping to the concept of micro-service data sovereignty. It is also often stated that event-based communication is preferable for resiliency. I believe these concepts collide.

Take for the following example: Micro Service A: Newsletter Service Micro Service B: Email Delivery Service Service A need the newsletter to be delivered in order to complete its task; thus Service A clearly has a dependency on B

A message is created by service A using an event contract defined by B and put it in a queue. For A to recognize the async response (success/failure), service A will have to attach an identity to the message which service B will have to relay back. I believe this is a reverse dependency and should be avoided.

Instead, I now think the following makes more sense and provides better separation.

Service A will synchronously invoke B with a message contract defined by B. B will then immediately return an identity that is owned by B and stored by A. The response indicates the operation has been queued but not yet handled. It will also return the name of the queue/topic to which the response is published. This is important because I believe the queue/topic should be owned by the service, which is publishing events. Service A will have to put this operation on an internal queue to have resiliency in case service B is temporarily unavailable. When the message is delivered, it will contain the identity of the message, which is fine because the identity is owned by service B itself.

I am very interested to hear your thoughts on this approach.