Containers Azure Container Apps premium

Dapr pub/sub

Dapr pub/sub is a Dapr building block that lets services publish messages to topics and subscribe to them through a configured broker component. In plain English, it helps teams send business events between services without tightly coupling every publisher to every subscriber or broker SDK. You see it when Container Apps use Service Bus or Event Hubs components, teams need event-driven microservices, or new subscribers should not rewrite publishers. The practical question is who owns it, which Azure resource proves it, and what breaks if it is missing.

Back to glossary browser Open Microsoft Learn source
Aliases
Dapr pub/sub, DAPR pub/sub
Difficulty
intermediate
CLI mappings
4
Last verified
2026-05-13

Microsoft Learn

Dapr pub/sub is a Dapr building block that lets services publish messages to topics and subscribe to them through a configured broker component. Microsoft Learn places it in Dapr pub/sub in Azure Container Apps; operators confirm scope, configuration, dependencies, and production impact.

Microsoft Learn: Dapr pub/sub in Azure Container Apps2026-05-13

Technical context

Technically, Dapr pub/sub is backed by Azure configuration, identities, dependencies, logs, and deployment records. Operators validate it by checking the live resource, related permissions, health signals, and approved design notes. Treat it as production configuration: capture resource IDs, test failure behavior, use least-privilege access, and keep rollback notes beside the change record. Keep owner, scope, evidence, and rollback visible. Keep owner, scope, evidence, and rollback visible. Keep owner, scope, evidence, and rollback visible. Keep owner, scope, evidence, and rollback visible.

Why it matters

Dapr pub/sub matters because it lets event-driven applications grow without forcing every service to know every downstream dependency or broker implementation detail. In enterprise Azure work, the weak spot is rarely the feature name; it is the gap between design intent and live state. When teams skip this topic, they can create audit findings, production outages, ambiguous ownership, hidden costs, or brittle integrations that show up during an incident. A good glossary entry turns the idea into an operating checklist: confirm scope, dependencies, monitoring, approved owners, and measurable outcomes before the change reaches production. Keep owner, scope, evidence, and rollback visible.

Where you see it

Signals, screens, and Azure surfaces where this term usually becomes operational.

Signal 01

In the Azure portal, Dapr pub/sub appears around Container Apps Dapr components, app revisions, broker configuration, logs, and subscription route evidence, where owners confirm scope, settings, dependency health, and recent changes before approvals.

Signal 02

In CLI or IaC reviews, it appears in az containerapp env dapr-component, az containerapp show, az containerapp logs, and broker CLI checks, helping engineers compare intended configuration with live Azure state before release.

Signal 03

In monitoring and governance, it appears through broker backlog, Dapr sidecar logs, distributed traces, dead-letter counts, replica scaling, and subscriber error alerts, where teams track drift, failures, usage, and policy exceptions tied to owners.

When this becomes relevant

Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.

  • Plan and review production use of Dapr pub/sub across subscriptions and environments.
  • Troubleshoot incidents where Dapr pub/sub affects access, latency, message flow, governance, or compliance evidence.
  • Create audit-ready runbooks, dashboards, and change checks for Dapr pub/sub.

Real-world case studies

Different enterprise-style examples that show the term being used to hit measurable objectives.

Case study 01

Order event fanout

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Proseware Market, a online retail organization, needed order events to reach fulfillment, loyalty, and fraud services without each publisher depending on three downstream SDKs.

Business/Technical Objectives
  • Publish order events once and support multiple subscribers
  • Reduce direct service dependencies in checkout code
  • Keep fraud-review event latency under thirty seconds
  • Track dead-letter messages during peak sales
Solution Using Dapr pub/sub

Proseware configured a Dapr pub/sub component backed by Azure Service Bus in the Container Apps environment. Checkout published order-created events through the Dapr API, while fulfillment, loyalty, and fraud apps subscribed with scoped access and separate routes. The platform team monitored broker backlog, sidecar logs, subscriber replicas, and dead-letter counts, then added schema ownership to the topic catalog so future subscribers could join without changing checkout code. The architecture decision record captured owners, rollback steps, monitoring queries, and acceptance criteria so the operating team could support the design after launch. The architecture decision record captured owners, rollback steps, monitoring queries, and acceptance criteria so the operating team could support the design after launch.

Results & Business Impact
  • Checkout direct dependencies dropped from three to one event API
  • Fraud-review latency averaged twelve seconds
  • Dead-letter alerts caught malformed events during a sale
  • A loyalty subscriber was added without publisher changes
Key Takeaway for Glossary Readers

Dapr pub/sub decouples publishers and subscribers while keeping broker operations visible.

Case study 02

Grid telemetry events

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Northwind Energy, a utilities organization, collected inverter telemetry and needed several analytics services to consume events without overloading the ingestion service.

Business/Technical Objectives
  • Separate telemetry ingestion from analytics subscribers
  • Sustain one million daily telemetry events
  • Detect subscriber backlog before service impact
  • Allow new analytics services to subscribe safely
Solution Using Dapr pub/sub

The ingestion container published normalized telemetry events through a Dapr pub/sub component connected to Event Hubs. Analytics, alerting, and billing services subscribed with scoped app IDs and independent scale rules. Engineers used sidecar logs, Event Hubs metrics, subscriber replica counts, and distributed traces to validate throughput. Payload contracts were reviewed before new topics or subscribers were introduced, keeping the ingestion code stable while analytics use cases expanded. The architecture decision record captured owners, rollback steps, monitoring queries, and acceptance criteria so the operating team could support the design after launch. The architecture decision record captured owners, rollback steps, monitoring queries, and acceptance criteria so the operating team could support the design after launch.

Results & Business Impact
  • Daily event volume reached one million without redesign
  • Backlog alerts fired before missed billing windows
  • Two analytics services joined without changing ingestion code
  • Subscriber scale tuning reduced processing delay by thirty percent
Key Takeaway for Glossary Readers

Dapr pub/sub is strongest when topic ownership and scaling are treated as production operations.

Case study 03

Enrollment notification mesh

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Citywide College, a education organization, needed admissions, finance, and student-success systems to react to enrollment changes without fragile nightly batch exports.

Business/Technical Objectives
  • Replace nightly export dependencies with near-real-time events
  • Keep student-success notifications under five minutes
  • Prevent unauthorized services from subscribing to sensitive topics
  • Create simple evidence for auditors reviewing student data flow
Solution Using Dapr pub/sub

The college deployed Container Apps with Dapr enabled and configured a Service Bus pub/sub component for enrollment events. Component scopes restricted publishers and subscribers, and topic names reflected data sensitivity. Student-success services subscribed to approved routes while finance consumed only billing-relevant topics. Logs, broker metrics, and Dapr component definitions were exported during audit reviews so data stewards could prove which apps handled each event type. The architecture decision record captured owners, rollback steps, monitoring queries, and acceptance criteria so the operating team could support the design after launch. The architecture decision record captured owners, rollback steps, monitoring queries, and acceptance criteria so the operating team could support the design after launch.

Results & Business Impact
  • Notification delay fell from nightly batches to under three minutes
  • Unauthorized topic access was blocked by component scope review
  • Auditors received data-flow evidence from one dashboard
  • Batch export support tickets dropped by sixty percent
Key Takeaway for Glossary Readers

Dapr pub/sub helps institutions move from batch coupling to governed event flow.

Why use Azure CLI for this?

Use Azure CLI for Dapr pub/sub to collect repeatable evidence from live Azure resources without changing the JSON engine or relying on one-off portal screenshots.

CLI use cases

  • Confirm the live Azure scope, resource owner, and configuration state for Dapr pub/sub before an approval.
  • Capture repeatable evidence for audits, incidents, architecture reviews, and release checklists involving Dapr pub/sub.
  • Compare portal settings, IaC intent, and command output so drift is found before it becomes a production issue.

Before you run CLI

  • Confirm the active tenant, subscription, resource group, resource names, and environment before trusting any command output.
  • Start with read-only commands; use mutating commands only when a change ticket, rollback plan, and owner approval exist.
  • Check whether the command touches identity, keys, networking, secrets, billing, or production traffic before running it.

What output tells you

  • It shows whether Dapr pub/sub is configured at the expected Azure scope and whether live settings match the approved design.
  • It exposes resource IDs, identities, permissions, component names, encryption settings, logs, or status values needed for troubleshooting.
  • It helps reviewers connect a portal decision to concrete evidence that can be saved in an incident, audit, or release record.

Mapped Azure CLI commands

Dapr pub/sub operational checks

direct
az containerapp env dapr-component list --name <environment> --resource-group <resource-group>
az containerapp env dapr-componentdiscoverContainers
read-only Microsoft docs
az containerapp env dapr-component show --name <component-name> --environment <environment> --resource-group <resource-group>
az containerapp env dapr-componentdiscoverContainers
read-only Microsoft docs
az containerapp logs show --name <container-app> --resource-group <resource-group>
az containerapp logsdiscoverContainers
read-only Microsoft docs
az containerapp replica list --name <container-app> --resource-group <resource-group>
az containerapp replicadiscoverContainers
read-only Microsoft docs

Architecture context

Dapr pub/sub connects architecture decisions to identity, dependency, monitoring, cost, and operations evidence for production Azure environments.

Security

Security for Dapr pub/sub starts with controlling which apps can publish or subscribe and how broker credentials or managed identities are exposed to the component. Use component scopes, managed identities, Key Vault-backed secrets, broker RBAC, private endpoints, mTLS for Dapr calls, and monitored topic permissions where they apply to this pattern. Do not treat a portal screenshot as proof; verify resource IDs, scopes, role assignments, diagnostic logs, and exception approvals. The specific risk is a mis-scoped pub/sub component can let an unauthorized service publish sensitive events or consume topics outside its business boundary. The strongest design also documents what happens if the pub/sub component, broker permission, topic subscription, secret reference, or app ID is revoked, expired, or misconfigured during a production incident.

Cost

Cost for Dapr pub/sub comes from broker operations, message volume, dead-letter retention, Container Apps replicas, logging, tracing, retries, and schema governance effort. A configuration that looks free can still increase background usage, security reviews, monitoring volume, or support effort. Review pricing at the whole workflow level, not just the named feature. Good teams tag owners, compare environments, watch utilization, set budgets where possible, and retire unused components before small recurring charges become normalized platform waste. Cost reviews should include the dependency services that make the pattern work in production. Keep owner, scope, evidence, and rollback visible. Keep owner, scope, evidence, and rollback visible.

Reliability

Reliability for Dapr pub/sub depends on broker capacity, retries, subscriber readiness, idempotency, dead-letter processing, sidecar health, and scale settings for consuming apps. Test both the happy path and the failure path: message backlog, duplicate delivery, poison messages, missing routes, broker throttling, broken secrets, and subscriber scale limits. Production owners should know which metric or log proves the behavior is healthy, what alert fires first, and who can approve an emergency change. The design should include environment parity, rollback notes, recovery expectations, and service-specific limits so support teams are not rebuilding context during an outage. Keep owner, scope, evidence, and rollback visible.

Performance

Performance for Dapr pub/sub depends on message size, broker throughput, subscriber concurrency, retry policy, sidecar overhead, scale-out behavior, and end-to-end event latency. Measure it with production-shaped data and realistic failure modes, not a tiny test request. Check cold starts, retries, payload size, routing, scans, cache behavior, and logging overhead where they apply. Performance work should not weaken security or reliability; the best result is documented tuning that explains which metric improved, which tradeoff was accepted, and when the decision must be reviewed. Keep owner, scope, evidence, and rollback visible. Keep owner, scope, evidence, and rollback visible. Keep owner, scope, evidence, and rollback visible.

Operations

Operations for Dapr pub/sub should be repeatable enough that another engineer can verify the same state without guessing. Keep topic catalog, schema ownership, component YAML, subscription routes, broker dashboards, dead-letter runbooks, and release validation checks connected to the change record. Review the setting during deployments, access reviews, incident postmortems, cost reviews, and platform upgrades. Avoid one-off portal edits unless they are captured afterward in IaC or documented exception records. The operational goal is clear evidence: what exists, why it exists, how it is monitored, and when it should change. Keep owner, scope, evidence, and rollback visible. Keep owner, scope, evidence, and rollback visible.

Common mistakes

  • Treating Dapr pub/sub as a label instead of checking the exact resource, identity, dependency, and monitoring evidence.
  • Assuming development, test, and production are configured the same without comparing live output and deployment templates.
  • Running a mutating command during investigation before confirming blast radius, rollback steps, approval, and ownership.