Little late , yet still if it works, here is an approach.
Although ,I can see a good explaination here Queues and Topic Endpoints
Below is an approach :
Publish to a topic / topicEndpoint
Consume through Queue / topic Subscription
Example, lets say that a service publishes to a
Topic Endpoint Name = service1-topic-endpoint
Topic = singapore/management/created/version1
Create as many consumers as required which uses topic Subscription
Example, lets say we have below queues with topic Subscription
SINGAPORE.SOME_APPLICATION1.FLOW.VERSION1 with topic subscription as singapore/management/created/version1
SINGAPORE.SOME_APPLICATION2.FLOW.VERSION1 with topic subscription as singapore/management/created/version1
SINGAPORE.SOME_APPLICATION3.FLOW.VERSION1 with topic subscription as singapore/management/created/version1
…
and so on
Define, the maxTTL as per your need , each consumer shall be able to receive same msg , untill consumed
Pros: easy to implement
Cons: Single topic point of failure
Topic segregation would be better approach from my perspective, as topic hierarchy can help in taking flow load as per defined hierarchy. example, if singapore/management/«MANAGEMENT_TYPE»created/version1
MANAGEMENT_TYPE can be something from api calls. naming convention is only for illustration purpose.