Azure Service Bus topic and subscription design for microservice-type consumers

Question

I'm looking into using Azure Service Bus for publishing/delivering messages between different services in our application, and are trying to find a decent design for the topic and subscriptions within a Service Bus namespace.

The intent of the system is for service-a to publish a message with type service-a.test-event to a bus, and have any service listening on that event type get the message delivered. It will be a fairly low volume

I'm a bit torn on which of the following designs to use:

1. The Service Bus namespace has one topic events where all messages from all services are delivered. Any service subscribing to events from any other service create a subscription in this topic using filters to get the message types they want - one subscription per message type (eg. service-b-service-a-test-event).
2. The Service Bus namespace has one topic per publisher (eg. events-service-a). Any subscribing service to events from this service create a subscription in the topic using filters to get the message types they want - one subscription per message type (eg. service-b-test-event).

Service Bus seems to have a limit of 2000 subscriptions per topic, which as far as I can tell will be sufficient for us. If I had suspicions otherwise, option #2 would probably be the best choice (as I can have 10.000 topics per namespace). None of the other limitations of Service Bus, as far as I can tell, really impacts which of these options I should go for.

One additional requirement is that I want to have a service subscribing to any event from any service for recording reasons. If I went for option #1, that'd be very simple to implement. For option #2 however, that service needs to somehow make sure it has a subscription within any event topic in the namespace - and reconfigure itself once new topics are added and old topics are removed. That's outside the scope of this question, but a requirement for the design none the less.

Answer 1

When deciding about a topology, take into consideration things that matter to you the most. One of the principles of pub/sub is to decouple between publishers and subscribers. With topology #2 (topic per publisher) this principle is violates since every subscriber would have to know the name of the publisher. And if publisher of an event would change, all your subscribers would have to get that knowledge in order to re-subscribe. Topology #1 solves that problem by abstracting publishers away by using a single topic.

Also, the 2nd requirement you had (to audit all of the events) would be much easier to implement with this topology as you only have to maintain a single wiretap subscription on that topic.

You're correct about limitation of 2000 subscriptions per topic. Saying that, 2000 subscriptions is quite a lot. Once your system get to that number of subscribers, you'd probably want to review your architecture/topology anyway.

These two topologies are sound extremely similar to the NServiceBus on Azure Service Bus as a transport topologies. You could have a look to see some of the other ideas you could use for your topology, including benefits of one over another.

Disclaimer: I am working on NServiceBus Azure Service Bus transport. You don't have to use NServiceBus, though a lot of questions like the one you're posting here become a non-issue when you do.