Before learning the service, understand the problem that message brokers solve.

Systems that talk to each other

Modern applications are rarely a single program. An online shop has a website, an order service, a payment service, a stock service, a shipping service, and an email service. These parts must exchange information. The simplest way is a direct call: the order service calls the payment service and waits for the reply. This is called synchronous communication, and it is easy to understand.

Why direct calls hurt

Direct calls create tight coupling. If the payment service is slow, the order service is slow. If it is down, orders fail. If a sudden sale sends ten times the usual traffic, every service in the chain must scale at the same moment. A failure anywhere ripples everywhere, like one stalled car blocking a single-lane road.

The message broker

A message broker is a service that sits between senders and receivers. The sender hands over a message, which is a packet of data with a description, and the broker stores it safely. The receiver collects the message whenever it is ready. The sender does not need to know who the receiver is, whether it is running, or how fast it works. This style is called asynchronous messaging.

Benefits in plain words

Service Bus is a fully managed enterprise message broker offered as a cloud service.

Definition

Azure Service Bus is a managed message broker that supports queues for one-to-one communication and topics with subscriptions for one-to-many communication. Microsoft operates the servers, storage, replication, and patching. You create a namespace, create entities inside it, and start sending and receiving. There are no brokers to install and no disks to size.

What makes it enterprise-grade

Where it fits among Azure messaging services

Azure has several messaging services with different jobs, and the next chapters compare them. In short, Service Bus is for high-value business messages that need reliable processing, ordering, and error handling. Event Grid is for lightweight event notification and routing. Event Hubs is for streaming huge volumes of telemetry. Storage Queues is for simple, cheap, large queues without advanced features.

Typical places you will meet it

Service Bus appears wherever business processes must survive failures and bursts. Order processing in retail, payment instructions in banking, appointment workflows in healthcare, integration between a cloud application and a legacy system, and the coordination of microservices all use it. It also bridges environments, since an on-premises application can send messages that a cloud function consumes hours later. Its strength is not raw speed but dependability: messages are stored durably, tracked individually, and removed only when work is confirmed. If your design needs those properties, it is the natural candidate among Azure services.

A trustworthy guide describes the service as it is now. Verify every date on Microsoft’s current pages before acting.

Retirement of old clients and the SBMP protocol

Microsoft announced that the older Service Bus client libraries and the Service Bus Messaging Protocol, abbreviated SBMP, retire on 30 September 2026. The affected libraries are WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus, and the older Java library. The modern replacement is Azure.Messaging.ServiceBus, available since November 2020 in .NET, with equivalent modern libraries for Java, JavaScript, and Python. The date has now passed, so any application still on the old libraries should be treated as running without official support.

Other dated or notable changes

Everything starts with a namespace, and the tier you choose shapes what is possible.

The namespace

A namespace is a container for messaging entities, with its own unique address such as a name followed by the Service Bus domain. It provides the scope for access control, networking rules, and capacity. Queues, topics, and subscriptions live inside it. Many teams use one namespace per application environment, or per business domain, rather than one for the whole company.

The tiers

flowchart TD
  NS["Namespace: address, security, network rules"] --> Q1["Queue: orders"]
  NS --> Q2["Queue: payments"]
  NS --> T1["Topic: order events"]
  T1 --> S1["Subscription: billing"]
  T1 --> S2["Subscription: shipping"]
  T1 --> S3["Subscription: analytics"]
  Q1 --> DLQ1["Dead letter sub queue"]
  S1 --> DLQ2["Dead letter sub queue"]
        

Entities, limits, and growth

Each namespace has quotas for the number of entities, the size of each entity, and the number of concurrent connections, and these quotas differ by tier. Rather than memorizing them, check Microsoft’s quota page when designing, and record which limits your design approaches. A namespace that holds hundreds of subscriptions or thousands of sessions deserves a deliberate capacity review. Growth is easier when entities are created from templates and named consistently, because tooling can enumerate them, report on them, and apply policy to them automatically.

The queue is the simplest and most common entity.

How a queue behaves

A queue holds messages in the order they were stored. Senders add messages to the back. Receivers take them from the front. Each message is delivered to exactly one receiver, even if many receivers are attached to the same queue. This is the competing consumers model: workers compete for messages, and adding workers increases throughput.

Important queue properties

Several of these properties, namely partitioning, sessions, duplicate detection, and the express option, cannot be changed after the entity is created. Microsoft’s FAQ states that changing them requires creating a replacement entity, so decide them at design time.

Choosing queue settings with care

Lock duration should be a little longer than the typical processing time, so locks do not expire during normal work, but not so long that a crashed receiver blocks a message for many minutes. Maximum delivery count should reflect how many honest attempts make sense, usually a small number such as five to ten. Time to live should match business value: a stock alert that is useless after an hour should expire after an hour. Dead-lettering on expiry should usually be switched on so expired work is visible, not silently dropped. Writing these decisions in a short design note helps future maintainers understand why the numbers were chosen.

When one message must reach several different receivers, a topic replaces the queue.

Publish and subscribe

A topic accepts messages from senders just like a queue. Behind it are subscriptions, and each subscription behaves like its own virtual queue holding a copy of the messages that match its rules. Billing, shipping, and analytics services can each have a subscription to an order topic. The sender knows only the topic. New receivers can be added later with no change to the sender.

Rules and filters

Filters evaluate message properties, not the message body, so senders must set meaningful properties such as type, region, and priority. A message that matches no subscription filter is dropped from the topic, which is correct for events nobody wants but surprising if you forgot to create a rule.

flowchart LR
  P["Sender: order service"] --> T["Topic: order events"]
  T -- "type = created" --> S1["Subscription: billing"]
  T -- "region = EU" --> S2["Subscription: EU shipping"]
  T -- "all messages" --> S3["Subscription: audit"]
  S1 --> R1["Billing workers"]
  S2 --> R2["Shipping workers"]
  S3 --> R3["Audit processor"]
        

When to use a topic and when to keep a queue

A topic is not automatically better than a queue. If exactly one kind of consumer will ever process the messages, a queue is simpler, cheaper to reason about, and easier to monitor. Choose a topic when different consumers need different copies, when you expect new consumers over time, or when filtering by property saves work. Beware of creating a subscription per tiny need, since each subscription stores its own copies and has its own dead-letter queue to watch. A modest number of well-named subscriptions, each with a clear owner, keeps the system understandable.

To use Service Bus well, you must understand what a message contains and how a receiver says it is done.

Parts of a message

Two receive modes

In peek-lock mode, the receiver gets the message, the broker locks it, and the receiver later tells the broker the outcome. This is the safe default for important work. In receive-and-delete mode, the message is removed the moment it is delivered. It is faster but loses the message if the receiver crashes before processing, so it suits data you can afford to lose.

Settlement outcomes

Choosing a message format

The broker treats the body as bytes, so the format is your choice. Plain structured text such as JSON is readable and works across languages, while compact binary formats save space at the price of readability. Whatever you choose, set the content type so receivers know how to read the body, include a version in the subject or properties, and keep the body free of secrets that do not need to travel. Small, stable, well-documented messages are much easier to evolve than large, loosely defined ones, and they make filters and troubleshooting simpler.

Following one message from send to settlement shows where reliability and delay come from.

Step one: the send

The sender opens a connection to the namespace, authenticates, and sends the message over a protocol such as AMQP. The broker validates it, checks for duplicates if enabled, and stores it durably before acknowledging. Only after that acknowledgment is the message safe, so a sender that does not wait for it may lose data.

Step two: routing

For a queue, the message simply joins the queue. For a topic, the broker evaluates each subscription’s rules and places a copy in every matching subscription. If a scheduled time is set, the message is held invisibly until then.

Step three: delivery and lock

A receiver asks for messages. The broker hands over the next available one and locks it for the lock duration. During that time no other receiver sees it. The delivery count increments.

Step four: settlement or timeout

The receiver completes, abandons, dead-letters, or defers. If the receiver does nothing and the lock expires, the message becomes available again and will be delivered once more. When the delivery count reaches the configured maximum, the broker moves the message to the dead-letter queue automatically.

sequenceDiagram
  participant S as Sender
  participant B as Service Bus
  participant R as Receiver
  participant D as Dead letter queue
  S->>B: Send message
  B->>B: Validate, check duplicates, store durably
  B-->>S: Acknowledge
  R->>B: Request next message
  B-->>R: Deliver with lock, count = 1
  alt Success
    R->>B: Complete
    B->>B: Remove message
  else Transient failure
    R->>B: Abandon or lock expires
    B->>B: Message available again
  else Max deliveries reached
    B->>D: Move to dead letter
  end
        

Why durability and speed trade off

Storing a message safely before acknowledging it costs a little time, and that cost is the price of reliability. Sending many messages in a batch spreads that cost over all of them. Waiting for each acknowledgment before sending the next one is the slowest pattern, while sending in batches and awaiting the group result is much faster. Understanding where the time goes helps you resist the temptation to switch off safety features for small speed gains. For most systems, the right answer is to keep safety on and improve speed through batching, concurrency, and efficient clients.

Failures are normal. Good design decides what happens to the messages that cannot succeed.

The dead-letter queue

Every queue and every subscription has an automatic secondary sub-queue for dead-lettered messages. It cannot be deleted and has no special name to create. Messages arrive there for several reasons: the maximum delivery count was exceeded, the message expired with dead-lettering on expiry enabled, a subscription filter evaluation failed with that option on, or the application explicitly dead-lettered it with a reason and description.

Handling dead letters well

Looking at a dead letter with a calm method

When a dead letter appears, resist the urge to resubmit immediately. First read the reason and description, then the message properties, then the body. Ask whether this is a single bad message or the first of many. Check what changed recently, such as a deployment, a schema change, or a dependency outage. Decide whether the message can be fixed and resent, should be discarded with a record, or needs a human decision. Finally, add a test or a validation rule so the same defect is caught earlier next time. This simple routine turns every failure into a small improvement.

These features turn a simple queue into a tool for serious business workflows.

Sessions in everyday terms

Design cautions

Request and reply done carefully

Sometimes a caller really does need an answer. Service Bus supports this through a reply-to property and a correlation identifier: the requester sends a message naming where the answer should go, and the responder sends the reply with the same correlation identifier. The requester then matches replies to requests. Use a dedicated reply queue per requester or sessions per request, set a sensible time to live so stale replies disappear, and handle timeouts explicitly. This pattern is useful for long operations, but it should not replace simple direct calls for fast queries.

Azure has four common messaging services, and picking the wrong one is the most expensive early mistake.

Questions that decide

The services combine well. A common design has Event Grid announcing that a file arrived, a function converting the announcement into a business message on a Service Bus queue, and workers processing it reliably with retry and dead-lettering.

Combining services in one design

Real systems seldom use only one messaging service. A photo-sharing platform might use Event Grid to announce that an image was uploaded, a Service Bus queue to hold the processing jobs that resize and scan the image, Event Hubs to stream usage telemetry to analytics, and Storage Queues for a cheap background cleanup task. Each service is used for what it does best, and the connections between them are explicit. Drawing this map for your own system, with a short reason beside each choice, prevents the common problem of one service stretched far beyond its strengths.

Premium is not just a bigger Standard. It is a different capacity model.

Messaging units

A Premium namespace is built from messaging units, each a dedicated bundle of processing and memory. Microsoft documents sizes of 1, 2, 4, 8, or 16 units per namespace. Because the resources are not shared with other customers, throughput and latency are predictable. You are billed hourly for the highest number of units allocated during that hour, and scaling down in the middle of an hour does not reduce that hour’s charge.

Scaling guidance from Microsoft

You can scale before an expected peak, which is preemptive, or in response to observed metrics, which is reactive. Automation can adjust units based on metrics, but remember the hourly billing rule, so avoid rapid up and down cycles.

Large messages

Premium can carry messages up to one hundred megabytes using AMQP, while the HTTP interface is limited to one megabyte. Large messages have trade-offs: batching is not supported for them, throughput falls and latency rises as size grows, and the limit is checked on send. You enable the larger size on a queue or topic by setting its maximum message size.

Capacity planning for Premium

Sizing a Premium namespace starts with the numbers that matter: messages per second at peak, average and maximum message size, number of senders and receivers, and the work per message on the receiving side. Run a realistic load test that includes bursts and failures, because average traffic hides the moments that cause trouble. Record CPU and memory at each load level, then choose the number of units that keeps both comfortably below the scaling thresholds, with room for growth. Review the numbers every quarter, as new applications often arrive and quietly consume the headroom.

Partitioning spreads an entity across several message brokers to raise throughput and availability.

What partitioning does

In an unpartitioned entity, one broker and one store handle all messages, so the entity is limited by that broker. In a partitioned entity, messages are spread across several brokers and stores. Throughput is no longer limited by one broker, and a temporary outage of one store does not make the whole entity unavailable. The cost is that global ordering is not guaranteed across partitions.

Ordering with partitions

If order matters, use sessions or a partition key so that related messages land in the same partition. Messages sharing a session identifier or partition key stay in order relative to each other, while unrelated messages spread across partitions.

Choosing a partition key

A good key spreads load evenly while keeping related messages together. Using a customer identifier works when customers are many and similar in activity, but a few very busy customers can create hot partitions that limit throughput. Using an order identifier spreads load better but only keeps one order’s messages together. Check the distribution of your keys with real or realistic data before you commit. If one key is overwhelmingly common, consider adding a suffix to spread it, accepting that ordering then applies only within each suffix group.

How clients talk to Service Bus affects firewall rules, performance, and which libraries are safe to use.

Protocols and ports

The proprietary Service Bus Messaging Protocol, SBMP, was used by the oldest .NET library and is part of the 30 September 2026 retirement. Plan on AMQP, and use WebSockets only where outbound ports other than 443 are blocked.

Modern clients

The current libraries follow a clear design. A single client object represents one connection to the namespace and should live for the whole life of the application. From it you create senders and receivers, and a processor object that handles message receiving, concurrency, lock renewal, and error callbacks for you. Libraries exist for .NET, Java, JavaScript, Python, and others.

Connection hygiene

Long-lived connections are efficient but can be dropped by networks, load balancers, or service maintenance. The modern libraries reconnect automatically, retry transient failures with backoff, and surface errors through callbacks. Make sure your error handlers log the details and do not swallow exceptions. Configure retry options deliberately rather than relying on defaults, and test behavior by simulating network interruptions. Applications that handle disconnects gracefully rarely cause incidents, while those that crash or hang on a dropped connection become the weak link in an otherwise reliable design.

A message broker often carries orders, payments, and personal data, so access control must be deliberate.

Two ways to authenticate

Built-in data roles

Assign roles at the narrowest scope that works, such as a single queue, rather than the whole namespace. Use managed identities for applications running in Azure, so the platform provides credentials with nothing to store. Where shared access signatures are unavoidable, create separate policies for sending and listening, never share the namespace-level root policy with applications, and rotate keys on a schedule.

Encryption

Data is encrypted in transit with TLS and at rest with Microsoft-managed keys. Premium additionally supports customer-managed keys, which let you control the encryption key in your own key vault.

Separating duties between teams

In a shared namespace, a clean security model gives each application only what it needs. A producing service gets the sender role on the specific queue or topic it writes to. A consuming service gets the receiver role on the specific queue or subscription it reads. Operations staff who inspect dead letters receive a read-oriented or receiver role on those entities only for the time they need. Administrators who create and delete entities use a separate management role, ideally with time-limited elevation. Recording these assignments in templates makes reviews simple and removes surprise access.

Many organizations require that messaging traffic never crosses the public internet.

Network controls by tier

With a private endpoint, the namespace receives a private address inside your virtual network, and traffic stays on the Microsoft backbone. You can then disable public network access. On-premises systems reach the namespace through a VPN or dedicated circuit into that network. Private DNS must resolve the namespace name to the private address, which is the most common source of setup errors.

flowchart LR
  APP["Application in virtual network"] --> PE["Private endpoint"]
  ONP["On premises systems via VPN or ExpressRoute"] --> PE
  PE --> NS["Premium namespace"]
  INT["Public internet"] -. blocked when public access disabled .-> NS
        

Minimum TLS version

A namespace has a minimum TLS version setting. According to Microsoft, clients using an older version complete the TCP and TLS handshake but their requests eventually fail with an unauthorized response, so failures can look like permission problems. Microsoft documents TLS 1.2 as the baseline, with TLS 1.3 used on public endpoints by default. Before raising the minimum, confirm that every connecting service supports the required version. Changing the setting needs write permission on the namespace.

Testing network settings safely

Network changes can lock out legitimate clients quickly. Test in a non-production namespace first, and verify the full route from each client type: virtual machines, functions, container workloads, build agents, and on-premises systems. Check name resolution from each location, because the same name must resolve to a private address inside the network and may resolve differently elsewhere. Keep a documented rollback step, such as re-enabling public access with a restricted address list, and make changes during a window when support staff are available. A careful sequence prevents long outages caused by a single forgotten dependency.

A broker sits in the middle of your systems, so its failure stops everything. Plan for it.

Layers of protection

flowchart LR
  APP["Applications use alias name"] --> AL["Alias"]
  AL --> P["Primary namespace: region A"]
  P -. metadata sync .-> S["Secondary namespace: region B"]
  P -. fails .-> FO["Failover: alias points to secondary"]
  FO --> S
        

Deciding failover and failback

Failover is a business decision as well as a technical one. Define in advance who can order it, what evidence is needed, and how long you will wait for the primary region to recover. Decide how to treat messages that were in the primary at the time: some can be reprocessed from source systems, some need manual reconciliation, and some are safely lost. After failover, plan the return carefully. Switching back creates another disruption, so many teams stay in the new region until a quiet period and rebuild the other side as the new secondary.

A handful of patterns appear in almost every successful messaging design.

flowchart LR
  O["Order service"] --> TOP["Topic: order events"]
  TOP --> PAY["Payment service"]
  PAY --> PT["Topic: payment events"]
  PT --> INV["Inventory service"]
  PT --> ORD2["Order service handles failure"]
  INV --> ST["Topic: stock events"]
  ST --> SHIP["Shipping service"]
  PAY -. payment failed .-> COMP["Compensating action: cancel order"]
        

Idempotency is the common thread

Because delivery is at-least-once, every handler must give the same result when it sees the same message twice. Typical techniques include storing processed message identifiers, using natural keys with upsert operations, and making updates conditional on version numbers.

Choreography versus orchestration

Sagas can be built in two styles. In choreography, each service reacts to events and publishes new ones, with no central controller. It is flexible and decoupled, but the overall flow is hard to see. In orchestration, a coordinator tells each service what to do and tracks the state of the process. It is easier to understand and monitor, but concentrates logic in one place. Small flows with few steps often suit choreography, while long business processes with many branches and compensations benefit from an orchestrator. Whichever you choose, document the flow in a diagram that the whole team can read.

Service Bus becomes most useful when something automatically reacts to messages.

Protecting downstream systems

Automatic scaling of consumers can accidentally overload databases and external services. When a large backlog exists, a function app or container group may scale out aggressively and hit a limit elsewhere. Cap the maximum number of instances, limit concurrent handlers per instance, and use rate limits for external calls. Watch the downstream system as well as the queue. The aim is to drain the backlog as fast as is safe, not as fast as is possible, because a flooded dependency turns a backlog into failures and dead letters.

A queue that fills silently is an outage in slow motion.

Key signals

Send diagnostic logs and metrics to a Log Analytics workspace for longer retention and queries, and configure alerts through action groups to notify the owning team. Application telemetry should record message identifiers and correlation identifiers so a single business transaction can be traced across services.

Dashboards people will actually read

A useful dashboard answers a few questions at a glance: Is work arriving? Is work being completed? Is anything stuck or failing? Show incoming and outgoing rates side by side, the backlog, the age of the oldest message, and dead-letter counts per queue and subscription. Add resource usage for Premium namespaces. Keep the view to one screen with clear thresholds, and link each chart to the runbook that explains what to do. A dashboard that nobody understands or trusts is worse than none, because it creates a false sense of safety.

Most performance problems come from a few client behaviors, not from the service.

Lock duration and long handlers

If handling takes longer than the lock duration, the lock expires and the message is delivered again while the first handler is still working, causing duplicates. The processor can renew locks automatically, but the renewal window has limits. For long tasks, either extend the lock with a deliberate design, break the work into smaller messages, or save progress and use a separate long-running worker.

Measuring before and after

Tuning without measurement is guesswork. Before changing any setting, record throughput, average and high-percentile processing time, error rate, and queue age under a repeatable load. Change one thing at a time, such as batch size, prefetch count, or concurrency, and measure again. Keep the change only if the result improves without raising errors or duplicates. Write down the final settings with the load that justified them. When traffic grows or code changes, repeat the exercise, because yesterday’s best setting can become today’s bottleneck.

Costs follow the tier and the volume. Always confirm current prices on Microsoft’s pricing page.

Microsoft states that Service Bus does not charge for storage, that inbound data transfer and transfer within a region are free, and that traffic leaving the region is charged. Operations such as sends, receives, and management calls drive Standard cost, so batching and efficient polling reduce the bill. Premium cost is driven by the number of units and hours allocated.

Ways to save

Comparing tiers with a worked example

Consider a team sending a few million operations a month with moderate spikes and no need for private networking. Standard is likely the economical choice, because it charges for what is used. Now consider a platform handling steady, heavy traffic, requiring private endpoints and predictable latency for payment messages. Premium provides dedicated capacity at a fixed hourly price, and the predictable cost can be easier to budget. The crossover depends on volume and requirements, so build a simple model with your own numbers and revisit it when traffic or compliance needs change.

A broker gives you the tools. Reliable systems come from how receivers use them.

The three guarantees you can really have

In peek-lock mode, Service Bus provides at-least-once delivery: a message will be delivered one or more times until a receiver settles it. It cannot promise exactly-once processing, because a receiver can finish its work and crash before telling the broker. You can approach exactly-once effects by combining at-least-once delivery with idempotent handling, and by using duplicate detection on the sending side.

Retry strategy

Treating all failures the same causes trouble. Retrying a permanent failure ten times wastes capacity. Dead-lettering a transient failure loses good work. Separate the categories in code, and make the choice explicit.

Making handlers idempotent

Testing failure on purpose

Reliable systems are tested against failure before real failure arrives. In a test environment, send malformed messages, stop a downstream database, kill a receiver mid-processing, delay processing beyond the lock duration, and send the same message twice. Observe what happens to counts, dead letters, and data. Confirm that no work is lost, that duplicates cause no harm, and that alerts fire. Run these exercises regularly, and especially after changing libraries, hosting models, or settings, because assumptions that held last year may no longer be true.

When many teams share messaging, consistency matters more than cleverness.

Namespace strategy

A middle path works for many organizations: a shared Premium namespace for core business domains with strict role assignments per entity, plus separate namespaces for workloads that are noisy, regulated, or owned by external parties.

Standards worth writing down

Environments and promotion

Keep development, test, and production namespaces separate, with the same structure created from the same templates. This lets teams test message contracts, filters, and failure handling without risking production data. Use smaller or cheaper tiers where the features allow, but remember that some behaviors, such as private networking and large messages, exist only on Premium, so test those paths in a Premium environment before release. Promote changes to entities through the same review process as application code, and never edit production settings by hand without recording the change.

The retirement date of 30 September 2026 has passed. If you still have old libraries, migrate in a controlled way.

Inventory first

Search source code, dependency files, build outputs, and deployed packages for the old library names. Remember background services, scheduled jobs, utilities, and third-party products that embed the old libraries. Check connection strings for transport settings that force the older protocol, and check any firewall rules that were opened only for it.

Mapping old concepts to new

Careful points

Rolling out the migration safely

Migrate one application at a time, starting with a low-risk consumer. Deploy the new version beside the old where possible, send test traffic, and compare results. Keep a rollback plan, but remember that rolling back to a retired library only delays the problem. Communicate dates to every team that owns a sender or receiver, including those who may have forgotten they own one. After cutover, remove old packages from dependency lists, block them in build checks, and update documentation and templates so new projects start on the current libraries.

Experience from many systems shows recurring good and bad designs.

Four short stories show how the pieces combine.

A quick reference of what experienced teams do and what they avoid.

A sensible first ninety days

In the first month, inventory current queues, libraries, and credentials, then fix the highest risks: retired libraries, shared keys, and missing dead-letter alerts. In the second month, introduce standards: naming, templates, defaults, and idempotency guidelines, and move applications to managed identities. In the third month, improve resilience and efficiency: private networking where required, a tested disaster recovery plan, autoscaling on queue length, and a cost review. Each step stands alone and improves safety immediately.

Checklist for a new queue or topic

Before any new entity goes live, ask a short list of questions. Who owns it, and who is on call for it? What is the message contract, and where is it documented? Which settings are fixed at creation, and have they been chosen deliberately? What are lock duration, delivery count, and expiry, and why? Who may send and who may receive, using which identities? Which alerts exist for backlog, dead letters, and message age? What is the plan if the region fails? Ten minutes of answers at the start saves days of repair work later.

Most problems fall into a few families. Check metrics and logs first, then work through the table.

flowchart TD
  S["Messages not processed as expected"] --> Q1{"Is backlog growing?"}
  Q1 -- Yes --> Q2{"Are receivers running and connected?"}
  Q2 -- No --> F1["Check identity, network, TLS, library version"]
  Q2 -- Yes --> F2["Check handler speed, concurrency, downstream limits"]
  Q1 -- No --> Q3{"Dead letters increasing?"}
  Q3 -- Yes --> F3["Read dead letter reason and fix cause"]
  Q3 -- No --> Q4{"Messages missing from consumer?"}
  Q4 -- Yes --> F4["Check topic filters and sender properties"]
  Q4 -- No --> F5["Check duplicate detection and idempotency"]
        

Useful habits

Learning from incidents

After each messaging incident, write a short review that records what happened, how it was detected, how long it took to fix, and what changed afterwards. Focus on the system, not individuals. Look for missing alerts, unclear ownership, unsafe defaults, and assumptions that proved wrong. Add the lessons to this troubleshooting guide and to your templates, so the fix becomes the default for the next team. Over time, a library of small reviews becomes the most valuable documentation your platform has, because it describes how your real system fails.

Short answers to questions that beginners and architects ask most often.

Azure Service Bus is a managed enterprise message broker that decouples systems, absorbs bursts, and delivers important messages reliably. Good outcomes come from choosing the right entity and tier, handling failure deliberately, securing access, and keeping clients current.