I am in the early stages of designing the high-level structure of how two of our enterprise applications will broadcast to topics in the Azure Service Bus. I am a novice user of this technology, and after my preliminary reading of the documentation, I am tempted to use a simple solution: use a separate topic for each different event type that we want to broadcast.
I favor this solution (over using filters) since it provides the most granular control over shared access keys, the least amount of message throughput, and also allows for easy addition of removal of subscriptions on a per-topic basis.
The alternative solution is to use less topics (send multiple events to a single topic) and then configure filters to determine whether each message should go to a subscription. From a maintenance standpoint this seems needlessly more complex and far less convenient. Why should I bother with filters when I can create thousands of topics?
Can anyone provide feedback on the best approach?
Topology is an interesting topic (no pun intended).
When it comes to Azure Service Bus, I'm very used to the concept of messages being divided into two major categories
Commands have a single destination and an expectation for work. They carry enough information for the work to be executed and often the sender expects to see a response.
Events are intended to notify N number of subscribers about the facts that took place without carrying too much information or having any expectations for the receivers. The N could be one or more (or even none) of subscribers. There are no expectations about what subscribers should do with the events and therefore publishers and subscribers are decoupled.
For commands, I prefer a queue. A queue can be only consumed by a single logical recipient. No chance for the same command to be delivered to multiple logical recipients. This also helps with scaling-out/in the receiver based on the load/work it's expected to handle. This doesn't mean it has to be implemented that way. You could do a topic with a single subscription and achieve the same. But that would mean the message needs to "travel" internally from a topic to a subscription, which is queues as well. The benefit of this approach could be plugging additional subscribers, but then I would ask if it's not a YAGNI scenario.
For events, either one or several topics with multiple subscriptions. A single topic reduces the amount of coupling - subscribers only need to know that topic rather than multiple ones.
Hope this information helps.
Can anyone provide feedback on the best approach?
Will sum it up as hear all the recommendations, but validate those for the needs you have. There's no one best way, there are options that will help you derive the approach that serves your system's needs.
Disclaimer: What I've described is very much aligned with the topologies implemented by NServiceBus with a few variations I've added.