Since lesson 4.12.2, the Kladde has talked to Service Bus directly, through the Azure SDK and the outbox. There is a second way that Azure Container Apps offers built in: Dapr, the Distributed Application Runtime. Dapr puts a second process next to each app, the sidecar, and the app talks only to it: "publish this event," "call this service," "store this state." Which broker, which store and which protocol sit behind it is written in components, not in code. This lesson shows what that brings, what it costs and where Container Apps draws limits. At the end, you decide in an ADR whether the Kladde takes Dapr.

What Dapr offers

Dapr bundles recurring tasks of distributed systems in building blocks. The app calls them at the sidecar over HTTP or gRPC; in Container Apps, the sidecar listens on port 3500 for HTTP and 50001 for gRPC.

Building block What it does Counterpart in the Kladde so far
Service invocation calls another app by its Dapr app ID, with retries and automatic mTLS between the sidecars HttpClient with service discovery and standard resilience (4.12.1, 4.12.2)
Pub/sub publishes and subscribes to events through a broker, such as Service Bus ServiceBusSender and receiver with an inbox (4.6.2, 4.6.3)
State management stores keys and values, transactionally too grain state, EF Core
Bindings triggers the app from outside events or writes to outside systems background services, Azure Functions
Secrets reads secrets from a store such as Key Vault AddAzureKeyVault, managed identity
Configuration reads and subscribes to settings .NET configuration
Actors stateful objects, one message at a time Orleans grains (module 4.5)

The promise is interchangeability: the app says "pub/sub tenders-pubsub," and whether Service Bus, Event Hubs or Kafka is behind it is decided by a component. Whoever has many programming languages in one system or wants to move between clouds gains a lot. Whoever has one language and one cloud gains less, and more comes on top of that shortly.