Building reliable Azure Service Bus pub/sub consumers with .NET

Cloud applications often need to distribute an event to several independent services. An order may need to update inventory, send a customer notification, create an accounting record and trigger an analytics workflow. Sending the same message separately to every service creates tight coupling and makes future changes expensive.

Azure Service Bus topics provide a durable publish/subscribe model for this situation. A .NET publisher sends one message to a topic, while separate subscriptions receive their own copy. Each consumer can process the event at its own pace, apply filters and recover from temporary failures without interrupting the publisher.

Understanding topics and subscriptions

A Service Bus topic is the publication endpoint. Applications send messages to it, rather than directly addressing individual consumers. A subscription behaves like a virtual queue attached to that topic. Every eligible subscription receives a separate message copy, with its own delivery state, lock and dead-letter queue.

For example, an Australian retailer could publish an OrderPlaced event to an orders topic. The fulfilment subscription might update warehouse systems in Melbourne, the notifications subscription could send an SMS, and the reporting subscription could forward data to an Azure analytics service. None of these consumers needs to know the identity or availability of the others.

Subscriptions may use SQL-like rules to select messages. A message containing an area property could be routed to a regional workflow, while a channel property might distinguish online purchases from store transactions. Filters should reflect meaningful business boundaries rather than becoming a second, difficult-to-maintain programming language.

A topic and subscription must be provisioned before messages are sent. Production deployments commonly use Bicep, Terraform or the Azure SDK instead of creating entities manually in the portal. Infrastructure as code makes names, permissions, duplicate detection and retention settings visible in source control.

Designing the .NET publisher

The modern Azure.Messaging.ServiceBus package is the preferred client library for .NET applications. A publisher normally creates a ServiceBusClient, obtains a sender for the topic, serialises a message and sends it asynchronously. The client is designed for reuse, so creating a new client for every request should be avoided.

await using var client = new ServiceBusClient(connectionString);
ServiceBusSender sender = client.CreateSender("orders");

var message = new ServiceBusMessage(BinaryData.FromObjectAsJson(new
{
    OrderId = order.Id,
    CustomerId = order.CustomerId,
    Total = order.Total,
    CreatedUtc = DateTimeOffset.UtcNow
}))
{
    Subject = "OrderPlaced",
    ContentType = "application/json",
    MessageId = order.Id.ToString()
};

message.ApplicationProperties["channel"] = "online";
await sender.SendMessageAsync(message);

The event contract should remain stable and carry a schema version. Consumers may be upgraded at different times, particularly when services are maintained by teams in Sydney, Brisbane and Perth. Additive changes, tolerant readers and explicit versioning are safer than renaming or removing fields without a migration plan.

Use managed identity and Azure role-based access control wherever possible. A workload hosted in Azure App Service, Functions, Container Apps or AKS can authenticate without storing a connection string in configuration. Local development can use environment variables or user credentials, while production secrets remain in Azure Key Vault.

Publishing should be tied carefully to the business transaction. If an application saves an order in a database and then fails before sending its event, downstream services will never see it. The transactional outbox pattern records the event with the business change and publishes it through a separate worker, providing a reliable bridge between a relational database and Service Bus.

Choosing delivery, ordering and settlement behaviour

Service Bus delivery is at least once. A message can be delivered again after a timeout, process termination or network problem, so consumers must be idempotent. A consumer can store processed event identifiers, use a database uniqueness constraint or make the operation itself safely repeatable.

A receiver obtains a lock while handling a message. Successful processing calls CompleteMessageAsync; a temporary problem can call AbandonMessageAsync, allowing redelivery. A permanent or malformed message should be dead-lettered with a reason that helps operations teams diagnose the issue.

The .NET processor handles receiving, locking and callbacks:

var options = new ServiceBusProcessorOptions
{
    MaxConcurrentCalls = 8,
    PrefetchCount = 40,
    AutoCompleteMessages = false
};

await using var client = new ServiceBusClient(connectionString);
await using var processor = client.CreateProcessor("orders", "fulfilment", options);

processor.ProcessMessageAsync += async args =>
{
    var order = args.Message.Body.ToObjectFromJson<OrderPlaced>();

    await fulfilmentService.ReserveStockAsync(order);
    await args.CompleteMessageAsync(args.Message);
};

processor.ProcessErrorAsync += args =>
{
    logger.LogError(args.Exception, "Service Bus processing error");
    return Task.CompletedTask;
};

await processor.StartProcessingAsync();

MaxConcurrentCalls increases throughput, but it also increases pressure on databases, APIs and warehouse systems. PrefetchCount can reduce latency, yet an excessive value may cause messages to sit in a client buffer until their locks expire. Measure processing duration and tune these settings using realistic workloads.

Sessions provide ordered processing for related messages, such as all events for a single customer or shipment. They are useful when sequence matters, though they reduce flexibility and can create a hot session. Global ordering across a busy topic is usually a sign that the event design needs reconsideration.

Controlling failures and duplicate work

A retry policy should distinguish transient faults from invalid data. A short outage in an Australian payment gateway may justify several delayed attempts, while a missing OrderId should be dead-lettered immediately. Exponential back-off prevents a failing dependency from being overwhelmed by rapid redelivery.

The maximum delivery count on a subscription determines when Service Bus moves a message to its dead-letter subqueue. Dead-letter records should include the original message, delivery count and failure reason. An operations process can inspect, correct and replay safe messages rather than silently discarding them.

Poison-message handling deserves an explicit ownership model. A support team may need to know whether a failure belongs to fulfilment, finance or a partner API. Azure Monitor alerts can track active messages, dead-letter counts, oldest message age and processor errors. These signals are more useful than a simple “application is running” health check.

Australian businesses also need to consider the Privacy Act 1988 and the Notifiable Data Breaches scheme when message bodies contain personal information. Customer names, addresses and contact details should be minimised, encrypted in transit and protected through least-privilege access. If a service sends data outside Australia, contractual and privacy requirements should be assessed rather than assuming that cloud location alone resolves compliance concerns.

Operating consumers across Australian workloads

A consumer may run as an Azure Function, a background worker in App Service, a container in AKS or a .NET process on a business server. Functions are convenient for variable workloads, while a continuously running worker provides more predictable control over concurrency and connection lifetime. The choice should follow processing duration, scaling behaviour and operational ownership.

Time handling is a common source of defects. Store event timestamps in UTC and convert them for display or local business rules. Sydney and Melbourne observe daylight saving time, while Brisbane does not, and Perth uses a different local offset. A message that says “run at 9 am” without a time zone is ambiguous across Australian offices.

Network architecture also affects reliability. Private endpoints, virtual network integration and firewall rules can improve security, though they require careful DNS and routing configuration. A consumer deployed in Melbourne may experience different latency from a dependency hosted in another Azure region. Regional placement, failover expectations and data residency should be documented before production launch.

Australian teams often schedule releases around customer activity and after-hours support availability. A national retailer may have heavy traffic during evening mobile shopping, while a regional service may depend on links with higher latency. Load tests should include peak periods, network interruptions and consumer restarts rather than testing only a quiet weekday morning.

Applying practical implementation safeguards

A clear event envelope helps every subscription interpret a message consistently. Useful fields include an event identifier, event type, schema version, occurrence time, producer name and correlation identifier. The business payload can then evolve without losing traceability across several services.

Logging should include MessageId, correlation data, subscription name and processing duration. Do not log access tokens or unnecessary personal information. Distributed tracing with OpenTelemetry can connect an HTTP request, the publisher and each downstream consumer, making it easier to find whether delay occurred before publication or during processing.

The following checks keep a pub/sub implementation predictable:

• Reuse ServiceBusClient, sender and processor instances.
• Set explicit lock renewal, concurrency and prefetch values.
• Make every handler safe to run more than once.
• Monitor active, deferred and dead-letter message counts.

Operational ownership should cover these areas:

• Define who investigates dead-lettered messages and how replay is authorised.
• Test managed identity permissions in a non-production subscription.
• Record retention, namespace region and disaster recovery assumptions.
• Exercise consumer shutdown during message processing.

Infrastructure should use separate namespaces or clearly isolated entities for development, test and production. Naming conventions can include the environment and bounded context, such as prod-orders and fulfilment. Access should be granted to the specific topic or subscription required by each workload instead of giving every service namespace-wide privileges.

Securing and scaling the complete flow

Azure Service Bus supports Standard and Premium tiers with different capabilities, throughput expectations and isolation characteristics. Premium messaging provides dedicated resources and is often appropriate for sensitive or high-volume workloads that need predictable performance. The selected tier should match message volume, latency targets and recovery requirements.

Scaling consumers horizontally is straightforward when messages are independent. Multiple instances can share a subscription and compete for messages, while separate subscriptions allow different capabilities to scale according to their own workload. Session-based consumers need extra care because a single session is processed by one active receiver at a time.

Testing should cover publisher retries, duplicate delivery, dead-letter replay, expired locks, revoked permissions and a restarted consumer. A useful test publishes one event, deliberately fails a handler, verifies redelivery and then confirms that the final business state is correct. Contract tests can ensure that a new publisher version remains compatible with existing .NET consumers.

For an Australian deployment, resilience planning should identify the impact of an Azure regional outage, an internet carrier interruption and a dependency failure in another state. Recovery point and recovery time objectives should be connected to actual business processes. With durable messaging, explicit contracts, secure identity and observable consumers, Azure Service Bus topics become a dependable boundary between independently evolving .NET services.