Azure Service Bus Topologies with Forwarding

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

In the previous blog post, I introduced topologies for Azure Service Bus and how topics and subscriptions can be leveraged to build reliable publish and subscribe infrastructure.

All the approaches described in the last post have one major drawback: Subscriptions need to be managed for all events the subscriber wants to subscribe to. This doesn’t sound like a huge deal given that a subscription is an entity that has to be created with its rules once on the broker. But subscriptions act like virtual queues. They store copies of messages that matched the rules in the subscriptions queue. Therefore the subscriber needs to attach one or multiple receivers to the subscription it manages. Every receiver attached to an entity has its own concurrency limitations and receiving infrastructure managed by potentially multiple worker threads. A subscriber does not only have to manage the receive infrastructure for every event it wants to subscribe to but also the receiving infrastructure for its own input queue. The overhead grows the more events are subscribed to and it becomes increasingly more complex to manage concurrency limitations over all the messages that are received by a subscriber no matter whether they are events that came in via subscriptions or other messages that were enqueued directly in the input queue of the subscriber.

Wouldn’t it be nice if we could automatically enqueue all messages in the input queue of the subscriber without having to manage receiving infrastructure for all subscriptions? The good news is we can achieve that by leveraging an Azure Service Bus feature called auto forwarding.

When the subscriber creates a subscription all it has to do is to set the ForwardTo property of the subscription to its input queue like the following pseudo-code illustrates

var sub = new SubscriptionDescription ("Bundle", "Subscriber.EventA");
sub.ForwardTo = "Subscriber";
namespaceManager.CreateSubscription(sub));

Once this is done any attempt to try to receive messages from the subscription will fail because the subscription is in auto-forwarding mode.

With the auto-forwarding enabled whenever a message that was published to the Bundle topic matches a rule in a subscription the subscription will create a copy of the message and auto forward it into the input queue of the subscriber as shown above. You might already have spotted that the above topology can even be simplified by having multiple rules under the same subscription as illustrated below.

In the Azure Service Bus adapter of NServiceBus the ForwardingTopology leverages the aforementioned auto-forwarding approach intensively to completely decouple subscribers from publishers and to simplify the resources consumed by a single consumer.

In the next post I’ll dive into the characteristics of the EndpointOriented as well as the Forwarding Topology of NServiceBus, the reasons why Particular wants to slowly migrated existing customers over to the Forwarding Topology and how the migration scenario has been designed to enable zero-downtime migration.

On a final note: In this post I did not go into the details of the auto-forwarding feature of Azure Service Bus. If you are curious to learn more about auto-forwarding I suggest you the excellent post “Auto Forwarding, a hidden gem of Service Bus” of my colleague Sean Feldman on the serverless 360 blog. Btw serverless360 has also a bunch of great content around Azure Service Bus.