Azure Service Bus Topologies of NServiceBus

  1. Azure Service Bus Topologies
  2. Azure Service Bus Topologies with Forwarding
  3. Azure Service Bus Topologies of NServiceBus (current)
  4. Azure Service Bus Topology migration with NServiceBus (next)

Almost a decade ago Particular Software started supporting customers running on Azure Service Bus by leveraging a robust and reliable queue abstraction called NServiceBus. Particular Software has been one of the early adopters of the PaaS Service. Hundreds of customers later we can look back at many scars and assumptions we made in our code base. One of those “scars” is the way we got started with setting up our first topology.

Like described in previous posts in this series there are different ways of creating topologies to manage entities such as queues, topics and subscriptions and their relationship to each other. The first topology approach that we used wasn’t leveraging forwarding. It used simple conventions to implement a Publish-Subscribe mechanism. The topology was called Endpoint-oriented topology.

In the EndpointOrientedTopology each publishing endpoint creates a topic called <publishing_endpoint_name>.events. The subscribing endpoints subscribe to the topic, by creating a subscription for a particular event type called <subscriber_endpoint_name>.<event_type_name>. Note that each subscription has a single rule, used to filter a specific event type.

When a publisher raises an event, it is published to the publisher topic. Then the subscription entities filter events using the associated rules. Finally, the subscriber endpoint pulls events for processing.

The example below demonstrates a publisher called Publisher and a subscriber called Subscriber. Publisher can raise two events, EventA and EventB. The Subscriber subscribes to both events and two subscription entities are created, one per event type. Each subscription entity filters out events using a rule associated with the subscription.

The EndpointOrientedTopology topology had several drawbacks we became aware of over time:

  1. In order to subscribe to an event, the subscriber must know the publishing endpoint’s name, causing coupling between publisher and subscriber.
  2. Multiple subscription entities per subscriber cause polymorphic events to be delivered multiple times to the subscribing endpoint.
  3. When a single subscriber is offline for an extended period of time and events are not consumed, it can cause event overflow. Since a single topic per publisher is used for all the subscribers, when event overflow is happening it will affect all subscribers and not just the one that is offline.

Once forwarding was implemented on the broker we knew this feature could enable us creating a better suitable topology that could overcome the drawbacks mentioned above. For new customers we created the ForwardingTopology that used the single topic approach described in earlier posts. In this topology Subscriptions are created under topic bundle 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 enables a complete decoupling between publishers and subscribers. All messages received by subscription are forwarded to the input queue of the subscriber. The scenarios described for the endpoint oriented topology would look like the following in the forwarding topology.

Unfortunately for quite some time this made the Azure Service Bus and NServiceBus story a bit more difficult than it should have been. Customers already using the EndpointorientedTopology could not move to the ForwardingTopology because those two topologies were not compatible. New customers were faced with making an educated choice about which topology they wanted to use. For many years we supported both topologies.

When Microsoft announced the new Azure Service Bus client that was compatible with .NET Standard we were forced to implement a new transport because many of the existing configuration options were no longer existent. For that new transport, we wanted to support one topology only which is the superior ForwardingTopology thus enabling all the benefits of that topology and also reducing the number of choices our clients had to make. In order to allow a smooth transition for existing customers we created an online migration path that I’m going to elaborate in the next post.

About the author

Daniel Marbach


By Daniel Marbach

Recent Posts