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.

Subscription 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.

Multiple rules under one subscription

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.

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.

About the Author:

Daniel Marbach is a Solution Architect at Particular Software Ltd and the CEO of tracelight GmbH. His experience spreads from client and server development to building distributed systems. Daniel has an engineer degree from the University of Applied Science in Horw. He has strong skills in Extreme Programming Practices such as Continuous Integration, Acceptance Test Driven Development and Test Driven Development. Daniel has extensive knowledge in the .NET ecosystem including NoSQ L databases, asynchronous programming, open-source software development and much more. He is a Microsoft MVP for Integration,  a frequent speaker, coach and passionate blog writer. Daniel co-founded the .NET Usergroup Central Switzerland and continues his journey of software development with passion.

In his professional life, Daniel has worked for many companies, mainly focusing on software development for industrial, technological or medical applications. Examples include the implementation of firmware upgrade tool for field engineers of a company specialized in breastfeeding and health care, labor analysis software for gene expression and genetic variation with PCR-based light cyclers for a global player in the medical industry, a secure and hybrid elevator configuration utility for an elevator company, architecture and coaching from the introduction up to the marketability of an automated guidance system, coach for Agile Engineering Practices and co-architect of a highly distributed medical customer management system. In his current position, Daniel is improving and extending the Particular Platform and helping customers to develop thriving distributed systems with NServiceBus.

Reference:

Marbach, D. (2019). Azure Service Bus Topologies with Forwarding.  Available at: https://www.planetgeek.ch/2019/01/14/azure-service-bus-topologies-with-forwarding/ [Accessed: 5th February 2019]