CH05-02: Queues and Reliable Messaging with Service Bus

Goal

The previous section separated commands, events, streams, and workflows. This section focuses on commands and reliable work handoff.

Azure Service Bus is a fully managed enterprise message broker. In plain language, it gives systems a durable place to put messages when another system must process work reliably, even if the receiver is slow, busy, or temporarily unavailable.

The durable idea is:

Use Service Bus when the message represents work that must be processed reliably.

The Short Version

Service Bus is a strong fit when a message is more than a notification. It is useful when the business cares that the work is processed.

Examples include:

Fulfill this order.
Reserve this inventory.
Send this invoice.
Process this refund.
Update this downstream business system.

The receiver might be offline. The receiver might fail halfway through. Traffic might spike. Service Bus helps decouple the producer from the consumer by storing messages until a receiver can process them.

Order API -> Service Bus Queue -> Fulfillment worker

The producer can accept the order and place work on the queue. The fulfillment worker can process that work at a manageable pace.

Queues

A Service Bus queue is usually used for point-to-point work delivery.

The model looks like this:

Producer -> Queue -> Consumer

The producer sends a message. The queue stores it. A consumer receives and processes it. Multiple consumer instances can read from the same queue to share the work.

This pattern helps with:

Temporal decoupling: producer and consumer do not need to be online at the same time.
Load leveling: spikes can be buffered rather than overwhelming the receiver.
Resilience: failed processing can be retried.
Scale: several consumers can process messages in parallel.

Queues are useful when one unit of work should be processed by one receiver or one receiver group.

Topics and Subscriptions

Service Bus also supports topics and subscriptions.

A topic is useful when multiple consumers need their own durable copy or filtered view of a message.

Order API -> Service Bus Topic
          |-- Inventory subscription
          |-- Billing subscription
          |-- Shipping subscription

Each subscription behaves like a durable queue from the receiver's perspective. Inventory, billing, and shipping can each process their own copy independently.

Use topics when the message still needs reliable processing, but more than one receiver has a legitimate processing responsibility. This is different from casual event notification. A subscription represents work that somebody owns.

Reliability and Failure Behavior

Reliable messaging is not only about storing messages. It is also about what happens when processing is messy.

Service Bus designs should consider:

Concern	Why It Matters
Retry behavior	Temporary failures should not automatically lose business work.
Idempotency	A message may be delivered or attempted more than once, so repeated processing should not corrupt state.
Dead-letter queues	Messages that cannot be processed need a visible place for investigation.
Ordering	Some workflows need messages processed in a defined order, often within a business key or session.
Time-to-live	Some messages expire because the work is no longer relevant.
Poison messages	Malformed or unexpected messages should not block healthy processing forever.
Monitoring	Queue depth, processing failures, retries, and dead-letter counts should be observable.

The important lesson is that a queue does not remove failure. It gives you a controlled place to handle failure.

Commands, Not Casual Facts

Service Bus is often the wrong tool when the message is only a lightweight fact.

For example:

Product image uploaded.

That may be a good Event Grid notification if subscribers only need to react. But if the next step is:

Generate compliant product assets and do not lose this work.

Then a Service Bus message may be appropriate, possibly started by an Event Grid event. The distinction is the business meaning. Is the system announcing a fact, or handing off work that must be processed?

Example: Order Fulfillment

Imagine a customer places an order. The order API validates payment details and records the order. Fulfillment may take time, and the fulfillment service might be under load.

A queue-based design could look like this:

Customer checkout
    |
    v
Order API records accepted order
    |
    v
Service Bus Queue: fulfill-order
    |
    v
Fulfillment worker reserves stock, creates shipment, updates status

This design lets the order API remain responsive while fulfillment continues asynchronously. It also gives operations teams something measurable: queue depth, message age, failure rate, and dead-letter messages.

The fulfillment worker must still be designed carefully. If it receives the same message twice, it should not ship two orders. If inventory is unavailable, it should record a clear failure state. If a message is malformed, it should not crash every worker repeatedly without ending up in a dead-letter queue.

Design Checklist

Before using Service Bus, answer these questions:

Question	Good Design Signal
What business action does the message represent?	The message has a clear command or reliable processing responsibility.
Who owns the consumer?	A team is accountable for processing and failures.
What happens if processing fails repeatedly?	Dead-letter handling and operational response are defined.
Can the handler process duplicates safely?	Idempotency is designed into the consumer.
How will the team know work is stuck?	Queue metrics and alerts are in place.
Is ordering required?	The design defines the scope of ordering, such as per order or per customer.

These answers are part of the architecture, not implementation trivia.

Common Mistakes

Using event notification where durable command processing is required.
Forgetting idempotency when messages may be retried.
Ignoring dead-letter queues until production incidents happen.
Creating topics and subscriptions without clear ownership for each consumer.
Putting complex business routing rules into broker filters instead of keeping business decisions in owned services.
Sending large payloads through the broker when a claim-check pattern with Blob Storage would be cleaner.

If Someone Asks You

When should you use Azure Service Bus?

A good answer is:

I use Service Bus when a message represents work that must be processed reliably. Queues fit point-to-point work handoff. Topics and subscriptions fit publish-subscribe messaging when each subscriber needs a durable processing path. I design retries, idempotency, dead-letter handling, monitoring, and ownership from the start because durable messaging makes failure manageable, not invisible.

What You Should Remember

Service Bus is for reliable work handoff, not just awareness that something happened.

Questions to Check Your Understanding

Why does durable messaging matter for business commands?
When would a topic be better than a queue?
Why should a Service Bus design include dead-letter handling?