Service Bus Topics in many-to-many communication

Marcin 26 Reputation points


I need to design a communication platform for different services (part of the same application). They will need to exchange particular events in order to maintain consistency. Typically Service Bus Topics with multiple subscriptions are used for that purpose (one-to-many communication). However, it would make my life easier if all components used the same topic to publish events (many-to-many). Then subscriptions could filter out only those events that are important to them. So in the end this will decrease the amount of topics and subscriptions and would help me achieve a simpler design (instead of having one topic per publisher with multiple subscriptions; a single consumer might then have multiple subscriptions if it needs data from multiple publishers).

I have read all Service Bus constraints and limitations in the Microsoft documentation and was not able to find out if multiple components using a single topic is a good idea. Will I hit any limitations or encounter known problems? If two services (A and B) would publish events to that topic, will the order be maintained on the subscribing-side? As far as I understand, sessions are used per publisher, so perhaps this cannot be guaranteed.

I would appreciate if somebody could shed more light on this.

Best regards,

Azure Service Bus
Azure Service Bus
An Azure service that provides cloud messaging as a service and hybrid integration.
338 questions
No comments
1 vote

Accepted answer
  1. Sean Feldman 191 Reputation points

    The assumption about the topology is correct. Building a topic per subscriber is almost an anti-pattern as it couples publishers and subscribers. Having a single topic solves that problem. In terms of performance, there should not be an issue. The broker team would be explicit about recommending against this type of topology if there'd be severe performance implications.

    Regarding ordered messages, the Sessions feature is not for publishers. It's for publishers and consumers. It will have a certain drawback such as no scaled-out processing for sessioned messages processing, but that's an acceptable trade-off given you want messages to be ordered.

    No comments

1 additional answer

Sort by: Most helpful
  1. Marcin 26 Reputation points

    Thank you for a clear explanation. I was not suggesting to create a topic per subscriber, but per publishing service. Nevertheless, now it is more clear that a single topic could be the way to go. Thanks a lot!

    No comments