This chapter covers Azure Service Bus, a managed messaging service, at the level AZ-900 expects: what it is, why applications use it, and how it compares to simpler alternatives. AZ-900 tests this under objective 2.2, as one of several application and integration services covered in the Azure Architecture and Services domain.
Jump to a section
A simple way to picture Azure Service Bus Messaging
Imagine two departments in a company that need to exchange paperwork, but they don't want to depend on someone from each department being available at the exact same moment to hand documents over directly. Instead, they use a mailroom: Department A drops paperwork into a labeled tray, and Department B collects it whenever it's ready — even if that's hours later. If Department B is temporarily out of the office, the paperwork just waits safely in the tray rather than being lost. Azure Service Bus works the same way for applications: instead of one application calling another directly and both needing to be available and fast at the same instant, the sending application drops a message into Service Bus, and the receiving application picks it up when it's ready. If the receiver is temporarily busy or down, the message waits safely instead of disappearing.
What Service Bus is and the problem it solves
Azure Service Bus is a fully managed messaging service that lets applications communicate by sending messages through Azure rather than calling each other directly. This "decouples" the applications: the sender doesn't need the receiver to be available at that exact moment, and a temporary slowdown or outage on one side doesn't immediately break the other.
The two basic patterns
Queues: one sender, one receiver. Messages are delivered in order, and each message is processed once. This is useful when you have a single stream of work to hand off — for example, an order-processing application queuing new orders for a fulfillment system to pick up.
Topics and subscriptions: one sender, multiple receivers. A message sent to a topic can be delivered to every subscription listening to it, so multiple independent systems can each react to the same event without the sender needing to know who's listening.
Why use it instead of calling directly
Without a messaging service, if application A calls application B directly and B is temporarily unavailable, that request typically fails and the work is lost unless the caller builds its own retry logic. With Service Bus in between, the message waits safely until the receiver is ready, without either side needing to be online at the same time.
Portal and CLI touchpoints
Namespaces, queues, and topics can be created through the Azure portal, or via CLI:
az servicebus namespace create --name myNamespace --resource-group myRG
az servicebus queue create --name myQueue --namespace-name myNamespace --resource-group myRGCreate a Service Bus namespace
A namespace is the container that holds your queues and/or topics — similar in spirit to how a resource group holds resources. It's created first, before any queues or topics.
Decide between a queue or a topic
If one system needs to hand work off to exactly one receiver, a queue fits. If multiple independent systems all need to react to the same message, a topic with subscriptions fits better.
Send and receive messages
The sending application sends a message to the queue or topic. The receiving application (or applications, for a topic) reads and processes messages whenever it's ready, rather than the sender waiting for an immediate response.
Compare against alternatives before committing
For very simple, high-volume, low-cost queuing needs without the enterprise messaging features, Azure Queue Storage is often a simpler and cheaper fit than Service Bus — this comparison is a common exam point.
An online retailer's checkout system sends a message to a queue whenever an order is placed, and a separate fulfillment system processes those messages to prepare shipments. If the fulfillment system needs a few minutes of maintenance, new orders simply wait in the queue instead of failing at checkout.
A logistics company uses a topic instead of a queue for shipment-status updates, because multiple systems — billing, customer notifications, and inventory — all need to know when a shipment status changes, and each can subscribe independently without the shipment system needing to call each one directly. Teams sometimes reach for Service Bus by default even for very simple, high-volume needs where the cheaper Azure Queue Storage would do the job — that mismatch is worth watching for when a scenario emphasizes very high volume, low cost, and no need for advanced features.
Objective 2.2 expects candidates to describe Azure's application and integration services at a conceptual level — for Service Bus specifically, that means knowing what it is, the difference between queues and topics, and when it's the right fit compared to a simpler alternative.
A common wrong answer is treating Service Bus as a database or long-term storage — it's designed for delivering messages, not storing data indefinitely. Another common trap is picking Service Bus for every messaging scenario without considering Azure Queue Storage, which is often more appropriate for simple, high-volume, low-cost queuing without enterprise features.
Stable terms worth knowing at this level: Queue, Topic, Subscription, Namespace. AZ-900 does not require implementation-level detail (message-locking internals, delivery-protocol specifics, or advanced enterprise messaging patterns) — that depth belongs to role-based exams like AZ-204.
Memory trick: one sender, one receiver, in order → queue. One sender, many independent receivers → topic and subscriptions. Simple, cheap, high-volume, no advanced features needed → consider Azure Queue Storage instead.
Azure Service Bus lets applications communicate through messages instead of calling each other directly, so a temporarily unavailable receiver doesn't lose work.
A queue delivers each message to one receiver; a topic can deliver the same message to multiple independent subscriptions.
Service Bus is for message delivery, not long-term data storage.
For simple, high-volume, low-cost queuing without enterprise features, Azure Queue Storage is often the more appropriate choice.
AZ-900 expects conceptual understanding of Service Bus — implementation-level detail belongs to role-based exams like AZ-204.
These come up on the exam all the time. Here's how to tell them apart.
Azure Service Bus
Supports both queues and topics/subscriptions
Built for enterprise messaging scenarios
Better fit when multiple systems need to react to one event
Generally higher cost, more features
Azure Queue Storage
Simple queue only, no topics
Built for very high-volume, low-cost queuing
Better fit for simple, single-purpose work queues
Generally lower cost, fewer features
Mistake
Service Bus stores data long-term like a database.
Correct
It's designed for message delivery between applications, not long-term storage — messages are meant to be picked up and processed, not kept indefinitely.
Mistake
Service Bus is always the right choice for any queuing need.
Correct
For simple, high-volume, low-cost queuing without enterprise messaging features, Azure Queue Storage is often a simpler and cheaper fit.
Mistake
A topic works like a queue but with a different name.
Correct
A queue delivers each message to a single receiver; a topic can deliver the same message to multiple independent subscriptions at once — they solve different problems.
Mistake
Applications using Service Bus must be online at the same time to communicate.
Correct
That's the opposite of the point — Service Bus lets the sender and receiver operate independently, with messages waiting safely until the receiver is ready.
A queue delivers each message to exactly one receiver, in order — useful for a single stream of work. A topic can deliver the same message to multiple independent subscriptions, so several different systems can each react to the same event without the sender needing to know who's listening.
Service Bus fits enterprise messaging scenarios — especially when you need topics for multiple receivers, or other advanced messaging features. For simple, high-volume, low-cost queuing without those needs, Azure Queue Storage is usually simpler and cheaper. The exam often tests this exact choice.
Service Bus is designed for reliable delivery — messages wait safely until a receiver picks them up rather than being dropped if the receiver is temporarily unavailable. AZ-900 doesn't require the implementation detail behind this; understanding that it improves reliability compared to a direct call is enough.
No. It's a messaging service for delivering messages between applications, not a place to store data long-term. Messages are meant to be processed and removed, not queried like database records.
You've just covered Azure Service Bus Messaging — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?