Skip to article
Integration Messaging

Service Bus topic

Service Bus topic is a publish-subscribe entity inside a Service Bus namespace. Publishers send one message to the topic, and matching subscriptions receive their own copies. Topics are used when several downstream systems need the same business event without coupling the publisher to every receiver.

Source: Microsoft Learn - Azure Service Bus queues, topics, and subscriptions Reviewed 2026-05-24

Exam trap
Creating one topic per application instead of per stable business stream, which makes fan-out brittle and hard to govern.
Production check
Show the namespace SKU and confirm it supports topics before creating or migrating topic resources.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
Azure Service Bus topic, Service Bus pub-sub topic, topic entity, broker topic
Difficulty
fundamentals
CLI mappings
6
Last verified
2026-05-24
Review level
template-specs-five-use-cases
Article depth
template-specs-five-use-cases-three-case-studies
Learning paths Learn Messaging and Streaming Foundations Service Bus topic
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

A Service Bus topic is where an application publishes a message when more than one downstream system may need it. Instead of sending the same event separately to billing, shipping, analytics, and notifications, the publisher sends one message to the topic. Subscriptions under that topic decide who receives a copy. A topic is not usually read directly by applications; receivers read from subscriptions. That design keeps producers simple and lets teams add or change consumers without rewriting the sending application.

Why it matters

Topics matter because they give architects a clean way to distribute important business events without building a fragile fan-out service. A producer can publish an order, claim, shipment, or telemetry command once, while several consumers receive durable, independently managed copies. That is a practical difference in production: one new consumer does not require producer code changes, slow consumers do not own the topic, and filtered subscriptions can control downstream noise. Topics also make event ownership visible. Operators can see the namespace, topic, subscriptions, rules, and backlog instead of chasing hidden webhook chains or custom retry loops. across teams, regions, and releases.

Technical context

Technically, a topic is a Service Bus entity created under a namespace, supported in Standard and Premium tiers. Producers send messages to the topic through the Service Bus data plane, and subscriptions receive copies according to rules and filters. Topic settings can include duplicate detection, default message time-to-live, partitioning where available, status, size limits, and authorization rules. It sits between application code, namespace-level networking and identity controls, subscription routing, Azure Monitor metrics, and infrastructure-as-code definitions for repeatable deployment.

Exam context

What to know

operator-ready Azure glossary term with practical use cases, CLI context, and structured case studies

Compare with

Service Bus queue Event Grid topic Event Hub

Where it is used

Where you see it

  1. In the Service Bus namespace Topics blade, topics appear with status, size, subscription count, duplicate-detection settings, and links to authorization rules and metrics. during production reviews.
  2. In deployment templates, topics appear as Microsoft.ServiceBus/namespaces/topics resources with properties for default TTL, duplicate detection, partitioning, and size-related limits. in governance reviews.
  3. In CLI inventory, az servicebus topic list and show reveal topic names, status, timestamps, message counts, and settings needed for drift checks. during drift reviews.

Common situations

  • Fan out one order, shipment, or claim event to multiple durable consumer streams without producer rewrites.
  • Add a new downstream system during modernization while keeping the existing publisher contract unchanged.
  • Use subscription filters to route business-event subsets instead of making every consumer process every message.
  • Replace fragile webhook chains with brokered delivery, retries, dead-letter handling, and measurable backlog.
  • Separate producer ownership from consumer ownership in a domain event architecture that still needs reliable messaging.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Airport operations hub replaces webhook fan-out Scenario, objectives, solution, measured impact, and takeaway.
Scenario

An airport operations hub sent gate-change notices through a chain of webhooks to signage, mobile apps, crew scheduling, and baggage systems. During irregular operations, one failed webhook retried aggressively and delayed every other downstream update.

Goals
  • Publish each gate-change event once from the operations system.
  • Give every downstream platform its own delivery stream.
  • Reduce cascading failures caused by webhook retry chains.
  • Add new consumers without modifying the operations system.
Approach using Service Bus topic

The architecture team created a Service Bus topic named gate-events and moved the operations system to publish one normalized event for every gate change. Signage, mobile notifications, crew scheduling, and baggage services each received a subscription with filters for the event types they owned. Duplicate detection protected repeated sends from the operations system during network retries. CLI scripts created the topic, listed subscriptions, and exported topic settings for airport change control. Dashboards tracked incoming messages at the topic and backlog per subscription so operators could separate publisher problems from consumer problems during disruption windows.

Potential outcomes
  • Gate-change propagation to mobile apps improved from 12 minutes to under 90 seconds during peak disruption.
  • Webhook retry incidents fell from eight per month to one minor alert.
  • A new passenger assistance consumer was added without changing publisher code.
  • Operations staff could identify the failing consumer from subscription metrics within five minutes.
What to learn

A Service Bus topic is powerful when one trusted event stream must feed several durable, independently operated consumers.

Scenario 02 Renewable energy operator distributes turbine events Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A renewable energy operator collected turbine status events and needed maintenance planning, grid reporting, anomaly detection, and warranty systems to receive different slices of the same stream. The previous batch export was slow and caused missed maintenance windows.

Goals
  • Distribute turbine status events within minutes instead of overnight.
  • Route only relevant event categories to each downstream team.
  • Preserve a single publisher contract from field telemetry ingestion.
  • Measure backlog and failures by consuming system.
Approach using Service Bus topic

Engineers introduced a Service Bus topic for turbine-status events after the ingestion layer normalized field telemetry. Subscriptions used rule filters for maintenance faults, grid-reporting events, anomaly candidates, and warranty claims. Maintenance received urgent fault events immediately, while analytics consumed broader but lower-priority event classes. The topic was deployed through Bicep and verified with Azure CLI topic and subscription listing commands. Operations dashboards showed incoming message rate, failed requests, and per-subscription active messages. The team documented message property names so future telemetry changes would not silently break filters.

Potential outcomes
  • Critical maintenance events reached planners in under three minutes instead of the next morning.
  • Warranty processing noise dropped 68 percent because its subscription filtered non-claim events.
  • Backlog ownership became visible per consumer instead of hidden in one export process.
  • Turbine downtime linked to missed alerts fell by 21 percent in the first quarter.
What to learn

Topics help high-volume operational data become useful business events without creating one custom delivery path per consumer.

Scenario 03 Streaming media studio coordinates asset publishing Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A streaming media studio produced asset-ready events when subtitles, artwork, encoding, and rights checks completed. Teams kept adding point-to-point queues, and producers became tangled with consumer-specific delivery rules.

Goals
  • Centralize asset lifecycle events into one durable pub-sub stream.
  • Let localization, catalog, quality review, and rights systems subscribe independently.
  • Reduce producer code changes when a new publishing workflow appears.
  • Improve troubleshooting for delayed catalog launches.
Approach using Service Bus topic

The studio replaced several direct queues with a Service Bus topic named asset-lifecycle. Producers sent events such as EncodingComplete, RightsApproved, and ArtworkReady with consistent message properties. Localization, catalog, quality review, and rights systems received subscriptions with rule filters matching their responsibilities. The catalog subscription used broader rules for launch readiness, while quality review consumed only exception events. CLI inventory was added to the release checklist so engineers could confirm topic existence, subscription count, and rule configuration before major content drops. Monitoring separated topic ingress from each subscription backlog.

Potential outcomes
  • Producer-side messaging code was reduced by 34 percent after consumer-specific routes were removed.
  • Catalog launch delay investigations dropped from 90 minutes to 20 minutes.
  • Two new localization workflows subscribed without a producer redeployment.
  • Major release weekends had zero messaging incidents tied to missing queue routes.
What to learn

A Service Bus topic keeps the publisher contract stable while letting many content workflows subscribe on their own terms.

Azure CLI

I use Azure CLI for topics because topic settings define the contract that every publisher and subscriber depends on. The portal is fine for a quick look, but CLI gives me repeatable inventory and proof: which topics exist, which tier they run under, whether duplicate detection is enabled, and which subscriptions hang below them. During incident review, I can export the topic and subscription shape in minutes and compare it with Bicep. For migrations, CLI also helps create topics consistently across environments, avoid spelling drift, and confirm that a namespace is not accidentally Basic. during audit reviews and incident calls.

Useful for

  • List topics in a namespace and verify the expected business streams are deployed.
  • Show topic properties to confirm status, duplicate detection, message TTL, and size settings.
  • Create topics consistently across environments from a release script or migration runbook.
  • List subscriptions below a topic to prove the fan-out shape during incident review.
  • Compare topic settings with Bicep output to detect drift before a deployment.

Before you run a command

  • Confirm tenant, subscription, resource group, namespace, topic name, and environment before running any create, update, or delete command.
  • Verify the namespace tier is Standard or Premium because a Basic namespace cannot host topics or subscriptions.
  • Check whether publishers, subscribers, and IaC templates already depend on the topic name before renaming or deletion.
  • Prefer read-only show and list commands before changing duplicate detection, TTL, status, or authorization settings.
  • Use JSON output for drift comparisons and include the namespace endpoint only in secure evidence handling.

What the output tells you

  • The topic status indicates whether publishers can send and whether operational changes have disabled the entity.
  • Duplicate detection and TTL settings explain why repeated messages may be suppressed or old messages may expire.
  • Subscription counts and related CLI output show whether fan-out matches the architecture diagram and release plan.
  • Created and updated timestamps help identify recent manual changes during incident or drift investigations.
  • Authorization-rule output shows whether access is scoped at the topic or inherited broadly from the namespace.

Mapped commands

Service Bus topic operations

direct 
az servicebus topic list --resource-group <resource-group> --namespace-name <namespace> --output table
az servicebus topicdiscoverIntegration
read-only Microsoft Learn 
az servicebus topic show --resource-group <resource-group> --namespace-name <namespace> --name <topic> --output json
az servicebus topicdiscoverIntegration
read-only Microsoft Learn 
az servicebus topic create --resource-group <resource-group> --namespace-name <namespace> --name <topic> --default-message-time-to-live P14D --output json
az servicebus topicprovisionIntegration
cost-impacting Microsoft Learn 
az servicebus topic update --resource-group <resource-group> --namespace-name <namespace> --name <topic> --status Active --output json
az servicebus topicconfigureIntegration
mutating Microsoft Learn 
az servicebus topic subscription list --resource-group <resource-group> --namespace-name <namespace> --topic-name <topic> --output table
az servicebus topic subscriptiondiscoverIntegration
read-only Microsoft Learn 
az servicebus topic authorization-rule list --resource-group <resource-group> --namespace-name <namespace> --topic-name <topic> --output table
az servicebus topic authorization-rulediscoverIntegration
read-only Microsoft Learn

Architecture context

Architecturally, a Service Bus topic is the central event distribution point for durable pub-sub messaging. I use it when the message is a command or business event that multiple systems may need, and where each consumer needs reliable brokered delivery rather than a best-effort notification. The topic owns the send contract; subscriptions own consumer-specific routing and backlog. A good design names topics around stable business streams, not individual applications. It also defines message properties for filters, duplicate detection requirements, publisher permissions, and observability. The topic should be boring, durable, and well documented because many workflows depend on it. over time.

Security
Topic security starts with the namespace boundary, network exposure, and the identities allowed to send or manage messages. Publishers should not receive Manage permissions just to send events, and receivers should normally read through subscriptions with least-privilege access. Topic-level authorization rules can narrow SAS access, but managed identity and Azure RBAC are often safer where supported by the client platform. Private endpoints, firewall rules, and diagnostic logs matter when topics carry regulated business data. A topic also creates indirect data exposure because any overly broad subscription can copy sensitive messages to a consumer that was not intended to see them.
Cost
Topics influence cost through message operations, retained messages, subscription fan-out, diagnostics, and downstream processing. Sending one message to a topic can create many brokered copies, and each copy can trigger compute, logging, storage, and support work. Duplicate detection and longer retention can be useful but should be sized deliberately. Cost surprises often come from stale subscriptions, broad filters, noisy publishers, or test topics left active in production namespaces. FinOps reviews should connect a topic to its owning business stream, expected message rate, subscription count, and cleanup rules. The cheapest design is usually the one that avoids unnecessary fan-out. and operational cleanup.
Reliability
Topic reliability comes from durable storage, subscription isolation, dead-letter behavior, duplicate detection where enabled, and clear publisher retry design. The topic can accept messages while subscribers process them at different speeds, but that does not remove the need for idempotent consumers and replay plans. Operators should monitor incoming messages, successful requests, server errors, throttling, and per-subscription backlog. A topic with many consumers can look healthy while one subscription is failing badly. Reliable architecture also protects the topic from accidental deletion, undocumented rule changes, and message property changes that break filters across several subscriptions at once. during releases and incident repair windows.
Performance
Topic performance depends on publisher rate, message size, batching, duplicate-detection windows, subscription count, filter complexity, namespace tier, and receiver capacity. Adding subscriptions can increase routing work and downstream load even when the producer changes nothing. A topic should be load-tested with realistic filters and message properties, not only with one subscriber. Operators should separate send latency from subscription processing latency, because publisher success does not prove consumers are keeping up. If predictable latency, private networking, or higher isolation becomes important, architects should evaluate Premium rather than forcing a busy Standard topic beyond its safe limits. before major launch peaks and cutovers.
Operations
Operators manage topics by checking namespace tier, topic status, size settings, duplicate-detection configuration, authorization rules, subscriptions, and metrics. Changes should usually be made through Bicep, ARM, Terraform, or reviewed CLI scripts because one topic can affect many teams. During incidents, operators confirm whether messages are entering the topic, whether subscriptions are receiving copies, and whether rules or downstream receivers are the bottleneck. Runbooks should include how to disable a topic safely, how to inspect subscription rules, and how to capture CLI evidence before deletion or migration. Ownership is critical because topics often outlive individual applications. in shared production namespaces and reviews.

Common mistakes

  • Creating one topic per application instead of per stable business stream, which makes fan-out brittle and hard to govern.
  • Assuming publishers can read from a topic directly; consumers receive from subscriptions, not from the topic itself.
  • Leaving broad subscriptions under a high-volume topic and making every downstream system discard messages in code.
  • Changing message property names without checking every subscription filter that depends on those properties.
  • Using namespace-wide Manage keys for topic publishers when Send-only access or managed identity would reduce blast radius.