Module 7 takes the agent you built in Module 6 and turns it into a production cloud service. You'll containerize the stack, orchestrate it on Kubernetes, automate delivery, and operate it with observability, security, and cost controls. The goal: a reliable Digital FTE that runs 24/7 for real users.
Prerequisites: Modules 4-6. You need a working agent service to deploy.
In earlier chapters, you built Kafka producers and consumers directly. You learned about topics, partitions, consumer groups, and offset management. That knowledge is valuable—but it's also tightly coupled to Kafka. If your team decides to use RabbitMQ for one service or Azure Service Bus for cloud deployment, you'd rewrite your messaging code.
Dapr's pub/sub building block gives you event-driven messaging through a single API. Your application publishes to /v1.0/publish/{pubsub}/{topic} and subscribes via HTTP callbacks. The actual broker—Redis, Kafka, RabbitMQ, AWS SNS/SQS—is defined in a YAML component file. Change the YAML, keep your code.
This is the same pattern you learned with state management: infrastructure abstraction through configuration, not code changes.
Dapr's pub/sub exposes two operations:
The key insight: publishing is an outbound call to Dapr, but subscribing is Dapr making inbound calls to your application. You register subscription handlers, and Dapr routes events to them.
When you publish through Dapr, your message gets wrapped in CloudEvents format automatically. CloudEvents is a specification for describing event data in a common way.
What you send:
What Dapr delivers to subscribers:
Why CloudEvents matters:
You don't need to construct CloudEvents yourself—Dapr handles the wrapping. Your subscriber receives the data field with your original payload.
Here's the async pattern for publishing events from your Todo API:
Output (Dapr sidecar logs):
Key parameters:
Before publishing works, you need a pub/sub component configured. Here's Redis:
Apply it:
Output:
That's it. Your publish_event() calls now route through Redis. No connection strings in code, no Redis client imports.
Dapr supports two subscription patterns:
Define subscriptions as Kubernetes resources:
Apply it:
Then implement the handler in your FastAPI app:
The dapr-ext-fastapi extension registers subscriptions directly in code—no CRD needed:
Output (when event arrives):
Which approach to use?
For this book's learning context, programmatic subscriptions are clearer—the subscription lives with the code that handles it.
Here's a complete FastAPI service that publishes and subscribes to todo events:
Testing the flow:
Output:
Logs show the subscription handler received the event:
Here's the power of Dapr's abstraction. You learned Kafka in earlier chapters. To use Kafka instead of Redis for pub/sub, change only the component YAML:
Apply the new component:
Your application code doesn't change. The same publish_event() and @dapr_app.subscribe() calls now route through Kafka instead of Redis.
When to use which broker:
The choice is now a deployment decision, not a code decision.
Your subscription handler must return a status that tells Dapr how to handle the message:
For critical events, prefer RETRY over DROP—let the broker's dead-letter handling manage truly unprocessable messages.
You built a dapr-deployment skill in earlier lessons. Test and improve it based on what you learned.
Ask yourself:
If you found gaps:
Setup: You have a Todo API using direct Redis pub/sub and want to migrate to Dapr's abstraction.
Prompt 1: Add pub/sub to your Todo API
What you're learning: The pub/sub integration pattern. You're seeing how Dapr's publish and subscribe APIs fit into existing FastAPI code without requiring broker-specific clients. The abstraction keeps your business logic clean.
Prompt 2: Swap brokers without code changes
What you're learning: Infrastructure portability in practice. The component YAML is the only thing that changes—your application remains broker-agnostic. This is why Dapr matters for production systems that may need to evolve their infrastructure.
Prompt 3: Understand CloudEvents format
What you're learning: CloudEvents as the interoperability standard for event-driven systems. Dapr handles the envelope automatically, so you don't construct CloudEvents manually—but understanding the format helps when debugging or integrating with external systems that expect CloudEvents.
Safety note: When testing pub/sub in production environments, use separate topics for testing. Publishing to production topics during development can trigger real workflows—notifications sent, orders processed, analytics skewed.