Ok, then I understand better what you would like to do.
I guess you have some kind of correlation id from R1/A1 that is passed along the request to the third-party api and then back in the response that may arrive at N2. Let’s call this a request-id. Do you use that as the topic id, i.e. creating a new topic for each request-id?
Topics should be long lived because there is rather much overhead of replicating and manage them, and as you have noticed it takes a while for other nodes to see that they exist after they have been created.
Unless you have very many nodes in the cluster a simple solution would be to broadcast the response to all nodes and filter on the destination side (in A1).
With Distributed PubSub you can use one single topic and one shared subscriber actor for that topic on each node. That subscriber actor will then have to delegate to interested local A1 actors.
Even simpler would be to use a Cluster aware group router and send messages with the
akka.routing.Broadcast wrapper. Also for this you will have one actor on each node with a fixed (know) actor path that other nodes can use as the broadcast destination. That actor will then have to delegate to interested local A1 actors.
An alternative design would be to use Cluster Sharding, with one entity actor for each request. That can short lived without problems. Then the entity actor corresponding to A1 would have to know how to respond to the frontend even though it might not be running on N1. Don’t know if that could be a problem, depending on what you use for the frontend communication from A1.
If you anyway would like to stick to your original design, although I wouldn’t recommend it, it is possible to ask Distributed PubSub for known topics by sending
DistributedPubSubMediator.GetTopics to the mediator, which will reply with
DistributedPubSubMediator.CurrentTopics. Then you would have to retry that on N2 until the known topic for the request shows up. Very inefficient, but your choice.