Azure Service Bus
What it is
Azure Service Bus is a managed enterprise message broker. It stores messages so one part of an application can hand work to another part without both being available at the same moment.
Think of a staffed dispatch desk. A customer-facing worker leaves a job card; a specialist picks it up when ready, completes it, and confirms it. The job card remains available if the specialist is briefly offline.
Why it exists
Northwind’s checkout site should accept an order even when the warehouse system is busy. A Service Bus message lets checkout hand off the picking task quickly. Workers can process tasks at their own rate, and extra workers can share a busy queue.
Key ideas
- A queue is point-to-point: a sender puts work in, and competing consumers each receive particular messages. It is useful for load leveling and independent processing.
- A topic is publish-subscribe: one sender publishes, and each matching subscription receives its own copy. Subscription filters can select only relevant messages.
- A receiver normally processes a message and then settles it as complete. If processing cannot finish, the message can be retried. Make consumers idempotent: processing the same message twice must not produce a harmful second effect.
- A dead-letter queue (DLQ) holds messages that could not be delivered or processed. It is an investigation and repair path, not a place to ignore failures.
- Sessions support ordered handling for related messages when the application uses a session identifier. Do not assume ordinary queue delivery is a blanket ordering guarantee.
Northwind example
After the order database records order 1042, the site sends a PickOrder message to a Service Bus queue. Warehouse workers compete for messages, so a lunchtime surge is shared rather than overwhelming one worker. A worker marks the message complete only after creating the picking task. If it fails before that point, a retry can occur; the worker checks the order ID so one order does not create two picking tasks. Repeated failures go to the DLQ for Maya’s team to investigate.
Service Bus, Queue Storage, and Event Grid
| Need | Start by considering |
|---|---|
| Simple work messages in an [[storage-account | Azure Storage account]] |
| Reliable business work, queues or topics, and richer broker features | Azure Service Bus |
| Notifications that a system state changed | [[event-grid |
These are starting points, not rules. The right choice depends on delivery, ordering, fan-out, protocol, cost, and operational requirements.
Common confusion
- Service Bus is not the business database. Store the order and its state in the system of record; the message asks another component to act.
- “Asynchronous” does not mean a task finished. It means the sender handed off the task and must use appropriate status, retry, and monitoring design.
- A dead-letter queue is not automatic recovery. Someone or a repair process must inspect, correct, or safely resubmit the message.
Related
queue-storage · event-grid · event-hubs · azure-functions · function-triggers · northwind-traders-case-study
Sources and re-audit
- Microsoft Learn — What is Azure Service Bus?, checked 2026-09-16.