6.1.3.2. Implement Azure Service Bus Topics

First Principle: Implementing Azure Service Bus Topics enables one-to-many asynchronous communication. Its core purpose is to provide a publish-subscribe messaging pattern, allowing multiple services to react independently to the same event through customizable subscriptions and reliable message delivery.

What It Is: Azure Service Bus Topics provide a "publish-subscribe messaging pattern", enabling "one-to-many asynchronous communication". When a message is sent to a "topic", all active "subscriptions" receive a copy, allowing multiple services to react independently to the same event.

Visual: "Service Bus Topic and Subscriptions"

Loading diagram...

Key Features:

• "Subscriptions": Each "subscription" acts as a virtual queue associated with a "topic", receiving all messages sent to that "topic".
• "Rules and Filters": "Subscriptions" can use "SQL or correlation filters" to receive only messages matching specific criteria, enabling targeted message delivery to specific consumers.
• "Message Sessions": "Sessions" allow grouping of related messages for ordered processing, ensuring that messages with the same session ID are handled sequentially by a single receiver instance.
• "Dead-lettering": Like queues, "subscriptions" have a "dead-letter queue" for unprocessable messages.

Publishing a Message (C# SDK):

using Azure.Messaging.ServiceBus;
// ... assume ServiceBusClient and ServiceBusSender are initialized for a topic
await sender.SendMessageAsync(new ServiceBusMessage("Hello, Topic!"));
// You can also add properties for filtering
// await sender.SendMessageAsync(new ServiceBusMessage("Order placed!") { Subject = "Order", ApplicationProperties = { { "Region", "EastUS" } } });

Creating a Subscription & Receiving Messages:

• Create "subscription" (Azure CLI):

  az servicebus topic subscription create --resource-group <rg> --namespace-name <ns> --topic-name <topic> --name <sub-name>
  

• Receive messages (C# SDK):

  ServiceBusReceiver receiver = client.CreateReceiver("<topic>", "<subscription>");
  ServiceBusReceivedMessage msg = await receiver.ReceiveMessageAsync(); // Receives one message
  // msg.body, msg.applicationProperties
  await receiver.CompleteMessageAsync(msg); // Mark message as processed
  

Common Use Cases:

• Event distribution to multiple "microservices" that need to react to the same event.
• Application notifications (e.g., sending an event to multiple internal systems when a customer order is placed).
• "Fan-out" for audit/logging/analytics where multiple systems consume a copy of the same data.
• Workflow orchestration where steps are initiated by a common event.

Scenario: A central order processing system publishes "Order Placed" events. A separate inventory management service needs to update stock, a notification service needs to send an email, and a logging service needs to archive the event. Each of these services needs to receive a copy of the "Order Placed" message independently.

Reflection Question: How does implementing Azure Service Bus Topics (with "subscriptions" and optional "rules/filters") fundamentally enable one-to-many asynchronous communication, allowing multiple services to react independently to the same event, supporting scalable and decoupled event-driven architectures?