Skip to content

Dapr Components, State, and Pub/Sub

Dapr building blocks such as state management and pub/sub are backed by components — declarative resources that bind a Dapr API to concrete infrastructure like Azure Cosmos DB or Azure Service Bus. This page covers how components are scoped in Azure Container Apps, how they reference secrets, and how to choose backing stores for state and pub/sub.

Components Are Environment-Level Resources

Unlike the Dapr sidecar setting (which is application-scoped), a Dapr component is defined at the Container Apps environment level. This lets multiple apps in the same environment share one broker or state store definition.

By default, every Dapr-enabled app in the environment loads every component. The scopes property narrows a component to specific apps by listing their Dapr application IDs (appId) — not the container app resource names.

flowchart TD
    subgraph ENV[Container Apps Environment]
        COMP["Dapr component<br/>pubsub (Service Bus)<br/>scopes: [order-service, shipping-service]"]
        A["order-service<br/>(Dapr appId)"]
        B["shipping-service<br/>(Dapr appId)"]
        C["billing-service<br/>(Dapr appId)"]
    end

    COMP -->|in scope| A
    COMP -->|in scope| B
    COMP -.->|out of scope| C

Scope every production component

Leaving scopes empty grants all Dapr-enabled apps access to the component. For least privilege, always list the exact appIds that need each state store, broker, or secret store.

Component Schema

Azure Container Apps uses a simplified Dapr component schema:

Field Purpose
componentType Dapr component type, e.g. state.azure.cosmosdb, pubsub.azure.servicebus.queue
version Component API version, typically v1
initTimeout How long Dapr waits for the component to initialize
ignoreErrors Whether the sidecar continues if the component fails to load
metadata Key/value configuration for the backing service
scopes Dapr appIds allowed to load the component
secretStoreComponent / secrets Reference to a Dapr secret store, or component-local secret parameters

Authenticating Components Safely

Never place connection strings or keys directly in component metadata. Azure Container Apps offers two authentication paths, in order of preference:

  1. Managed identity (recommended). For Azure-hosted backends that support it, Dapr authenticates using the managed identity of the scoped container apps. No secret material is stored in the component manifest. For a user-assigned identity, set the azureClientId metadata field.
  2. Azure Key Vault secret store. Use this only when managed identity authentication isn't supported. Create a secretstores.azure.keyvault component, then reference it from other components via secretStoreComponent and resolve sensitive fields with secretRef.
# Example: Service Bus queue pub/sub component that authenticates
# through a Key Vault secret store component
componentType: pubsub.azure.servicebus.queue
version: v1
secretStoreComponent: keyvault-secretstore
metadata:
  - name: namespaceName
    value: "mynamespace.servicebus.windows.net"
  - name: azureClientId
    value: "[your_client_id]"
  - name: azureClientSecret
    secretRef: sb-client-secret
scopes:
  - order-service
  - shipping-service

Choosing a State Store Backend

State management gives your app durable key/value storage with optimistic concurrency. Common Azure-backed options:

Backend When to use
Azure Cosmos DB Global distribution, high throughput, low-latency key/value
Azure Blob Storage Simple, low-cost persistence for coarse-grained state
Azure Table Storage Cheap key/value at scale with simple queries
Azure SQL / PostgreSQL / MySQL Relational durability, existing database estate
Redis Fast, ephemeral or cache-like state

State keys are namespaced by the app's appId, so two apps sharing a store do not overwrite each other's keys.

Choosing a Pub/Sub Broker

Pub/sub decouples publishers from subscribers using the competing-consumer pattern. Consumer grouping is keyed by appId, so all replicas of an app share the same subscription.

Broker When to use
Azure Service Bus (queues/topics) Enterprise messaging, ordering, sessions, dead-lettering
Azure Event Hubs High-volume event streaming and telemetry ingestion
Redis Streams Lightweight, low-latency messaging

Durability Trade-offs

  • At-least-once delivery: brokers like Service Bus and Event Hubs redeliver on failure, so subscribers must be idempotent.
  • Ordering: use Service Bus sessions or Event Hubs partitions when strict ordering matters; plain topics do not guarantee global order.
  • Scale-to-zero: an app scaled to zero replicas is not consuming. Use a Dapr/KEDA-aware scale rule so queued messages wake the app.

Component Resiliency (Preview)

Dapr supports resiliency policies (timeouts, retries, and circuit breakers) applied to component interactions, letting you tune how the sidecar handles transient backend failures without changing application code. On Azure Container Apps, Dapr component resiliency is a preview feature — confirm current availability before relying on it in production.

Limitations

  • Components are shared at the environment level; isolate sensitive backends by using separate environments or strict scopes.
  • Not every upstream Dapr component is available; prefer the Azure-backed types validated for Container Apps.
  • Secret values must be referenced, not embedded, to pass security review.

See Also

Sources