Azure Service Bus

Azure Service Bus is a fully managed enterprise message broker that provides reliable message delivery between decoupled applications and services. It supports both point-to-point (queues) and publish-subscribe (topics) messaging patterns with features like dead-lettering, sessions, transactions, and scheduled delivery.

Core mental model: Service Bus is a reliable mailbox with delivery guarantees. A producer drops a message in, and Service Bus ensures exactly one consumer processes it, with full control over retries, ordering, failure handling, and acknowledgment. Messages do not disappear until they are explicitly completed or moved to the dead-letter queue.

This is fundamentally different from a streaming log. In Event Hubs, events persist for all consumers to read. In Service Bus, each message is delivered to one consumer (queues) or one consumer per subscription (topics), and removed after processing.

Queues: Point-to-Point Messaging

A queue holds messages until a consumer is ready to receive and process them. Multiple consumers can compete for messages from the same queue (competing consumers pattern), but each message is delivered to exactly one consumer.

graph LR
    P1[Producer 1] --> Q["Queue"]
    P2[Producer 2] --> Q

    Q --> C1[Consumer 1]
    Q --> C2[Consumer 2]
    Q --> C3[Consumer 3]

    Q --> DLQ["Dead-Letter Queue"]

    style Q fill:#2d5aa0,color:#fff
    style DLQ fill:#a03030,color:#fff

How it works:

1. Producers send messages to the queue.
2. Consumers receive messages one at a time. The message is locked so no other consumer can see it.
3. The consumer processes the message and calls Complete() to remove it from the queue.
4. If processing fails, the consumer can Abandon() the message (returns it to the queue for retry) or let the lock expire.
5. After a configurable number of delivery attempts, unprocessable messages move automatically to the dead-letter queue.

FIFO ordering: Queues deliver messages in the order they were sent, as long as there is a single consumer or you use sessions to group related messages.

Topics and Subscriptions: Publish-Subscribe

Topics extend the queue model to fan-out scenarios. A producer sends a message to a topic, and Service Bus delivers a copy to each matching subscription. Each subscription acts like its own independent queue with its own consumers, delivery tracking, and dead-letter queue.

graph LR
    P[Producer] --> T["Topic"]

    T --> S1["Subscription: Orders"]
    T --> S2["Subscription: Notifications"]
    T --> S3["Subscription: Audit"]

    S1 --> C1[Order Processor]
    S2 --> C2[Email Service]
    S3 --> C3[Audit Logger]

    style T fill:#2d5aa0,color:#fff
    style S1 fill:#4a9e5c,color:#fff
    style S2 fill:#4a9e5c,color:#fff
    style S3 fill:#4a9e5c,color:#fff

Subscription filters let each subscription receive only the messages it cares about, based on message properties or SQL-like filter expressions. For example, the “Orders” subscription might filter for messageType = 'order' while “Audit” receives everything.

Key Features

Dead-Letter Queue (DLQ)

Every queue and subscription has a built-in dead-letter sub-queue. Messages land here when they cannot be processed after the maximum delivery count, when they expire, or when application code explicitly dead-letters them. This prevents poison messages from blocking the main queue and gives operators a place to inspect failures.

Sessions

Sessions provide ordered, grouped processing for related messages. All messages with the same SessionId are delivered to the same consumer in order. This is useful when you need to process a sequence of steps for a specific entity (user, order, workflow instance) and ordering matters.

Sessions also enable a simple distributed lock pattern: only one consumer can hold a session at a time.

Transactions

Service Bus supports local transactions that group multiple operations (send, complete, dead-letter) into an atomic unit. Either all operations succeed, or none of them take effect. This prevents inconsistencies like completing an incoming message but failing to send the outgoing one.

Scheduled Delivery

Messages can be scheduled for delivery at a future time. The message is accepted immediately but only becomes visible to consumers at the specified UTC time. Useful for deferred tasks, reminder patterns, or retry-after-delay strategies.

Duplicate Detection

When enabled, Service Bus automatically detects and discards duplicate messages based on the MessageId within a configurable time window. This protects against producer-side retries that might accidentally send the same message twice.

Message Deferral

A consumer can defer a message, removing it from the regular delivery flow but keeping it in the queue. The consumer can later retrieve it by its sequence number. This is useful when messages arrive in an order that does not match the processing order the application needs.

Tiers

Standard handles most workloads. Premium is for production systems that need network isolation, consistent latency, or Java EE integration via JMS 2.0.

Protocols

Common Use Cases

• Microservice decoupling - services communicate through queues instead of direct HTTP calls, improving resilience and independent deployability.
• Load leveling - absorbing traffic spikes in a queue so downstream processors can work at a steady pace.
• Distributed transactions - coordinating multi-step business processes where each step must complete reliably.
• Workflow orchestration - routing work items through sequential processing stages with sessions for ordering.
• Enterprise integration - connecting systems that operate at different speeds or availability patterns.
• Command processing - dispatching actionable work items (create account, send notification, process refund) to the right handler.
• Retry and error handling - leveraging dead-letter queues and delivery counts for systematic failure management.

Service Bus vs Event Hubs vs Queue Storage

Rule of thumb: Use Service Bus when someone must do the work and you need delivery guarantees. Use Event Hubs when you are building a streaming pipeline. Use Queue Storage when you need a cheap, simple queue and can handle the limitations.

In Entra-Adjacent Systems

Service Bus appears in identity-related architectures when systems need reliable command delivery and workflow coordination:

• Dispatching onboarding or provisioning commands that must reach downstream systems in sequence.
• Routing remediation tasks after Microsoft Graph detects configuration drift.
• Coordinating approval steps where a failed step must be inspectable in the dead-letter queue.
• Using sessions to ensure all workflow messages for a specific tenant or user are processed in order.

In these patterns, Service Bus acts as the workflow coordinator, while Cosmos DB holds supporting state and Event Hubs handles high-volume telemetry.