I am a long user of NServicebus and is on the current project (for the first time) using it with Azure Service Bus transport.
First I will explain how I understand NSB is using this transport. 1 single Topic. Each time a service subscribes to a new Event, a subscription is added (+ filter) that is forwarding the event to the service queue. The service (NServicebus) is only connected to the one queue, where all events and commands are received. There is only 1 dead letter queue for the service.
In my company other teams are using the native Azure SDK and they are deploying one topic per event. I do not think they understand the need for a local queue if you only are listening for Events. Messaging is very new to the organization, so with only 1 event in production, current subscriber implementations are quite easy. The subscriber simply connects to the subscription.
My worry is that in the future, when a service is subscribing to N events and also needs to receive commands, the service would need to have N+1 connected clients. Is this the case and do you think this is a problem? Also there must be many dead-letter queues belonging to the service, right?
You are correct in saying that all events are published to one single topic. Each NSB endpoint uses a single input queue to receive messages - either sent to it directly or through its subscription to published events.
Subscriptions are created under the single topic, with one subscription entity per subscribing endpoint. Each subscription contains multiple rules; there’s one rule per event type that the subscribing endpoint is interested in. This diagram might make it easier to visualize.
Since each NSB endpoint has one input queue, that results in one dead-letter sub queue.
Yes this aligns fine with my understanding on how NServicebus uses Azure Service Bus.
The reason for my post was more to discuss whether there could be issues with not using the same technique (forwarding to a single private queue) and just reading from multiple subscriptions from several different topics. (N+1 = N event subscriptions + 1 queue for commands/messages)
I don’t know but this is where my organization is heading. They are not using NServicebus, and are making a new topic for each event type. They are deploying subscribers reading from the subscriptions directly.
This will give you N azure client-connections where N is types of events. Is this feasible?
You should be aware that the number of client connections is not infinite. If the number of events is significant and clients are scaling out, you might hit the limit, which is 5,000 per namespace.