Implementing Publish-Subscribe with Azure Service Bus

1. From Queues to Topics: The Publish-Subscribe Model

In the last lesson, a sender sent a message to a queue, and a single receiver processed it. This is a point-to-point model. But what if multiple parts of your system need to react to the same event? For example, when a new order is placed, you might need to:

• Update inventory.
• Send a confirmation email.
• Notify the shipping department.
• Feed data into an analytics engine.

Sending a separate message to four different queues is inefficient. This is where the publish-subscribe (or "pub/sub") model excels.

In this model:

• A publisher sends a message to a Topic. The publisher doesn't know or care who is listening.
• The Topic forwards a copy of the message to one or more Subscriptions.
• Each Subscription acts like a virtual queue for an interested subscriber (or consumer).

This decouples the publisher from the subscribers, allowing you to add or remove new consumer services without ever changing the publisher's code.

2. Creating Topics and Subscriptions

Just like queues, topics and subscriptions live inside a Service Bus Namespace. The creation process is very similar to what you did in the previous lesson.

To see this in action, let's watch a short segment of a video that demonstrates how to create a topic and multiple subscriptions using the Azure Portal.

As you can see, a topic is the parent entity, and subscriptions are its children. Each subscription will receive a copy of every message sent to the topic unless you define specific filtering rules (which we'll cover shortly).

3. Implementing the Publisher and Subscriber in .NET

Here's the great news: your existing C# and .NET skills, and the code you wrote for queues, are almost directly transferable to topics and subscriptions. You'll use the same Azure.Messaging.ServiceBus library and the same core classes.

The key differences are minor:

• Publisher (Sender): Instead of creating a ServiceBusSender for a queue name, you create it for a topic name.
• Subscriber (Receiver): Instead of creating a ServiceBusProcessor for a queue name, you create it by providing both the topic name and the subscription name.

Let's review the official Microsoft documentation for the exact code.

The following video segment reinforces this by showing how code written for queues can be quickly adapted for topics.

4. Hands-On Lab: Implementing the Pub/Sub Pattern

Now it's your turn to build it. This lab will prove the pub/sub concept by having one publisher send a message that is received by two independent subscribers.

Part A: Create Resources and a Single Subscriber

1. In the Azure Portal:

   • Navigate to the Service Bus Namespace you created in the last lesson.
   • Create a new topic. Let's call it order-topic.
   • Create a subscription for this topic. Let's call it email-subscription.

2. In Visual Studio:

   • Create a new .NET Console App for your publisher. Name it TopicPublisher.
   • Create another .NET Console App for your first subscriber. Name it EmailSubscriber.
   • Publisher App (TopicPublisher): Using the code from the Microsoft Learn quickstart, implement a sender that sends a few messages to order-topic.
   • Subscriber App (EmailSubscriber): Implement a receiver that listens to order-topic and email-subscription.
   • Use the same RootManageSharedAccessKey connection string from your namespace.

3. Test:

   • Run the EmailSubscriber app first.
   • Then, run the TopicPublisher app.
   • Confirm that the EmailSubscriber console window shows the received messages.

Part B: Add a Second Subscriber

1. In the Azure Portal:

   • Go back to your order-topic.
   • Create a second subscription. Let's call it inventory-subscription.

2. In Visual Studio:

   • Create a copy of your EmailSubscriber project and rename it InventorySubscriber.
   • In the code for InventorySubscriber, change the subscription name from "email-subscription" to "inventory-subscription". The topic name remains "order-topic".

3. Test the Full Pub/Sub Flow:

   • Run the EmailSubscriber app.
   • Run the InventorySubscriber app. You should now have two console windows open and waiting for messages.
   • Run the TopicPublisher app.
   • Observe: Both the EmailSubscriber and InventorySubscriber console windows should display the messages. You've successfully broadcast a single message to two independent consumers.

The following video demonstrates a similar outcome using Azure Functions as subscribers, which is another common pattern.

5. Filtering Messages

A powerful feature of subscriptions is the ability to selectively receive messages using rules. By default, a subscription has one rule that accepts all messages. You can replace this with custom rules to route messages based on their properties.

The two main types of filters are:

• SQL Filters: Use a SQL-like WHERE clause to evaluate message properties. This is highly flexible.
• Correlation Filters: Perform a fast and efficient exact match against one or more message properties (like Subject or ContentType).

Let's imagine our Order messages have a Region property. We could create a subscription for "EU Orders" that only receives messages where Region = 'EU'.

You can add these properties to your message before sending it. Your experience with key-value pairs and dictionaries in C# will make this intuitive.

// In your publisher app
var message = new ServiceBusMessage("Your JSON payload here");

// Add custom application properties for filtering
message.ApplicationProperties["Region"] = "EU";
message.ApplicationProperties["Priority"] = "High";

await sender.SendMessageAsync(message);

The following article has excellent, modern C# code examples for creating filters and actions programmatically using the ServiceBusAdministrationClient.

Conclusion

Excellent work! You have now implemented the publish-subscribe pattern, a cornerstone of modern, event-driven applications on Azure. You've seen how a single event can be broadcast to multiple, decoupled services, allowing your system to scale and evolve with ease.

Key Takeaways:

• Topics and Subscriptions enable the one-to-many publish-subscribe messaging pattern.
• A message sent to a topic is copied to every subscription.
• The .NET SDK code for topics is nearly identical to the code for queues, making it easy to adapt. You use a topic name for the sender and a topic/subscription name pair for the receiver.
• Subscription Rules and Filters allow subscribers to selectively receive messages based on their properties, enabling sophisticated message routing.

Next Steps

In today's videos, you may have noticed mentions of the "dead-letter queue" (DLQ) when message processing fails. In our next lesson, we will formally cover this critical concept by learning how to configure message properties such as Time-to-Live (TTL) and manage dead-lettered messages. This is essential for building robust and fault-tolerant messaging solutions.