Build Async Messaging in .NET with Azure Service Bus (Step-by-Step)

Milan Jovanović

6 chapters8 takeaways12 key terms6 questions

Overview

This video introduces Azure Service Bus, a cloud messaging service for implementing decoupled, asynchronous communication between application components. It explains the core concepts of queues and topics, detailing their differences and use cases. The tutorial then walks through creating a Service Bus namespace, queues, and topics in the Azure portal, and setting up access policies. Finally, it demonstrates how to send and receive messages from .NET applications using the Azure Service Bus SDK, covering both queue and topic-based messaging patterns, and highlighting key features like message processing, error handling, and the use of connection strings with .NET Aspire.

How was this?

Save this permanently with flashcards, quizzes, and AI chat

Chapters

Azure Service Bus is a fully managed cloud messaging service that enables asynchronous communication between different parts of an application.
It helps decouple components, meaning they don't need to be available at the same time or know direct details about each other.
The service supports two primary messaging constructs: Queues and Topics.

Understanding these fundamental concepts is crucial for designing scalable and resilient distributed systems where components need to communicate reliably without direct dependencies.

A Queue is a point-to-point messaging pattern where a message is sent to the queue and consumed by a single receiver. Once processed, the message is removed.
A Topic is a publish-subscribe pattern. Messages are sent to a topic, which then distributes copies of the message to multiple 'subscriptions'.
Each subscription acts like a virtual queue, allowing different consumers to process the same message independently.
Topics are ideal when a single event needs to trigger actions in multiple, distinct parts of your system.

Choosing between queues and topics determines how messages are routed and consumed, directly impacting your application's architecture and its ability to handle one-to-one versus one-to-many communication scenarios.

A queue is like a single inbox where only one person can read and act on a message. A topic is like a central announcement board where multiple people can subscribe to different types of announcements, and each receives a copy of what's posted.

Scheduled messages: Publish messages to be delivered at a future time.
Deduplication: Automatically handles duplicate messages sent within a specific timeframe, primarily for network-related retries.
Dead-lettering: Moves messages that cannot be processed after multiple attempts to a separate 'dead-letter' queue for inspection.
Filtering: Allows subscriptions to topics to specify rules for which messages they are interested in, so only relevant messages are delivered.

These features enhance message reliability, manageability, and the ability to process only relevant information, leading to more robust and efficient messaging workflows.

Using filters on a topic subscription to ensure a 'shipping' service only receives order messages with a 'shipped' status, while a 'billing' service receives orders with a 'paid' status.

A Service Bus Namespace is a container for all your messaging entities (queues, topics). It's recommended to have one namespace per environment (dev, staging, prod).
Within a namespace, you can create individual Queues and Topics.
Shared Access Policies provide connection strings with specific permissions (e.g., send, listen, manage) for applications to connect to the Service Bus.
When creating a topic, it's essential to create subscriptions *before* sending messages to ensure no messages are missed.

Properly setting up namespaces, queues, topics, and access policies in Azure is the foundational step for enabling asynchronous communication in your applications.

Creating a 'standard' pricing tier namespace named 'my-app-prod-sb' in the Azure portal, then adding an 'orders' queue and an 'order-events' topic with a 'notifications' subscription.

Use the `Azure.Messaging.ServiceBus` NuGet package in your .NET application.
A `ServiceBusClient` is created using a connection string obtained from Azure.
Create a `ServiceBusSender` instance for a specific queue or topic.
Messages are created as `ServiceBusMessage` objects, often with a JSON-serialized body.
Custom properties can be added to messages for filtering or metadata, and a `MessageId` can be set for deduplication.

This demonstrates the practical implementation of sending data asynchronously from your application, enabling decoupled workflows and event-driven architectures.

Serializing an 'OrderCreated' event to JSON and sending it as a `ServiceBusMessage` to the 'orders' queue and the 'order-events' topic using `queueSender.SendMessageAsync()` and `topicSender.SendMessageAsync()`.

Use the `ServiceBusClient` to create a `ServiceBusProcessor` for queues or topics/subscriptions.
Configure `ServiceBusProcessorOptions`, such as setting `autoCompleteMessages` to `false` to manually complete messages after successful processing.
The processor uses callback methods for handling incoming messages (`ProcessMessageAsync`) and errors (`ProcessErrorAsync`).
After processing, call `message.CompleteMessageAsync()` to acknowledge successful handling, or `message.AbandonMessageAsync()` to release it for redelivery.
Consumers should be registered as background services (`AddHostedService`) to run continuously.

Implementing message consumption is the other half of asynchronous messaging, allowing your applications to react to events and process data reliably without constant polling.

Setting up an `OrderNotificationService` that uses a `ServiceBusProcessor` to listen to the 'notifications' subscription of the 'order-events' topic, deserializing incoming messages and calling `CompleteMessageAsync` upon successful processing.

Key takeaways

1Azure Service Bus enables robust, asynchronous communication by decoupling application components.
2Queues are for one-to-one message delivery, while Topics support one-to-many publish-subscribe patterns.
3Features like dead-lettering and filtering enhance message reliability and targeted processing.
4A Service Bus Namespace acts as a logical container for queues and topics, with namespaces typically scoped per environment.
5Connection strings from Shared Access Policies are used by .NET applications to authenticate with Service Bus.
6The `ServiceBusClient` in the .NET SDK is the entry point for creating senders and processors.
7Message processing requires explicit completion (`CompleteMessageAsync`) or abandonment (`AbandonMessageAsync`) to manage message lifecycle.
8Using .NET background services is an effective way to host message consumers that need to run continuously.

Key terms

Azure Service BusMessage QueueTopicSubscriptionNamespaceShared Access PolicyConnection StringServiceBusClientServiceBusSenderServiceBusProcessorDead-letteringMessage Filter

Test your understanding

1What is the primary difference between a Service Bus Queue and a Topic?
2How does Azure Service Bus facilitate decoupling between application components?
3What is the purpose of a Service Bus Namespace, and how should it typically be organized?
4Explain the role of subscriptions in the context of Service Bus Topics.
5How do you ensure that a message is only processed once by a consumer, and what happens if processing fails?
6What are the key steps involved in sending a message from a .NET application to Azure Service Bus?