Your TaskActor stores state. It processes method calls. But it sits idle, waiting for someone to invoke it. In real systems, actors don't just wait—they react. A new task arrives in a queue, and the actor springs to life. A cron schedule fires, and the actor performs cleanup. A webhook triggers, and the actor processes external data.
This is the difference between a responsive actor and a reactive one. Responsive actors wait for requests. Reactive actors respond to events from the world around them.
In Module 7.5, you learned about timers and reminders—internal scheduling within an actor. Now you'll connect actors to the broader event ecosystem: Dapr pub/sub for internal service events, and Dapr bindings for external triggers like cron schedules and webhooks.
Actors and events work together in a specific pattern. The actor handles state and logic. Events trigger and communicate between actors and services.
The critical insight: Dapr delivers events to your FastAPI application, not directly to actors. You create handlers that receive events and route them to the appropriate actor instance using ActorProxy.
When a pub/sub message arrives, Dapr calls a subscription endpoint on your FastAPI application. Your handler extracts the actor ID from the message and invokes the correct actor.
Subscription YAML:
FastAPI Subscription Handler:
Output:
You might wonder: "Why can't Dapr deliver messages directly to actors?"
The answer lies in actor semantics:
The subscription handler is the bridge—it maps event semantics (topic, payload) to actor semantics (ID, method).
Actors can also publish events outbound. This enables actors to communicate without knowing about each other.
Output:
When publishing events from actors, follow these patterns:
Include enough context in events for subscribers to route correctly:
Input bindings connect actors to external event sources. A cron schedule fires, and an actor wakes up. A webhook arrives, and an actor processes it.
Binding Component:
FastAPI Handler:
SchedulerActor Implementation:
Output:
External systems can trigger actors through HTTP bindings:
Binding Component:
FastAPI Handler:
Output:
Actors can invoke external systems using output bindings—sending HTTP requests, writing to storage, or triggering notifications.
Binding Component:
Actor Using Output Binding:
Output:
Here's a complete example integrating all patterns—an event-driven task management system:
actors.py:
main.py:
Output:
You built a dapr-deployment skill earlier in this chapter. Test and improve it based on event-driven actor patterns.
Does your skill understand the routing pattern—events to handlers to ActorProxy to actors?
Ask yourself:
If you found gaps:
Apply event-driven actor patterns to your domain.
Setup: Open Claude Code or your preferred AI assistant in your Dapr project directory.
Prompt 1: Pub/Sub to Actor Routing
What you're learning: The subscription handler is the bridge between topic-based pub/sub and ID-based actors. You extract the actor ID from the event payload and route to the correct instance. This pattern enables actors to react to events without knowing about pub/sub directly.
Prompt 2: Cron Binding to Actor
What you're learning: Cron bindings replace actor timers when you need application-level scheduling rather than per-actor scheduling. The handler pattern is the same—binding delivers to FastAPI, handler routes to actor via proxy.
Prompt 3: Actor Publishing and Output Bindings
What you're learning: Actors can be both event consumers and producers. Using DaprClient within actor methods lets you publish events (internal communication) and invoke bindings (external communication). This creates truly reactive actors that participate in broader event flows.
Safety Note: When processing events from pub/sub or bindings, always validate the payload structure before routing to actors. Malformed events should be logged and dropped (return SKIPPED), not crash your handler. Consider implementing a dead-letter pattern for events that fail processing.