At KubeCon + CloudNativeCon’s Kubernetes Community Days (KCD) 2025 in Austin, Whit Waldo, CEO and founder of Innovian, delivered an engaging talk titled “Harnessing Dapr Actors: Building Scalable Applications with Confidence”. Drawing from years of hands-on experience, Waldo walked the audience through the powerful actor model as implemented in Dapr (Distributed Application Runtime), emphasizing practical use cases, architectural strategies, and pitfalls to avoid.
Why Dapr?
Dapr is a runtime designed to simplify building microservices by offering a suite of abstracted building blocks—state management, pub/sub messaging, encryption, and notably, an actor model. Waldo explained that Dapr’s abstraction allows developers to swap infrastructure providers with minimal code changes, focusing more on business logic and less on plumbing.
Understanding the Actor Model
Actors, as Waldo noted, are not mere data records. They are isolated units of computation—programs with their own state and behavior—that process messages sequentially. This makes actor-based systems ideal for simplifying concurrency, managing state encapsulation, and building resilient event-driven architectures.
He compared traditional multi-threaded complexity to the elegant simplicity of actors: “bite-sized, single-threaded units” that avoid the usual pitfalls like deadlocks and race conditions.
When (and When Not) to Use Actors
Actors are not a general-purpose pattern. According to Waldo, they shine in:
- Event processing and ETL pipelines
- Agentic workflows
- Real-time systems like games
- Tasks requiring autonomous stateful behavior
He emphasized the importance of designing for intent. CRUD-based data can often remain outside actors, while autonomous, behavior-rich components benefit from being implemented as actors.
Designing with Dapr Actors: The Tetris Example
To illustrate these concepts, Waldo showcased a clever architecture of a Tetris game implemented using only two actors:
- Game Actor – Manages the game grid, scoring, piece history, rules, and timing.
- Tetrino Actor – Represents the active game piece, handling rotation, movement, and state transitions.
This minimal actor count highlights Waldo’s principle: avoid unnecessary complexity by treating related data and behavior as a single actor unless separation is functionally warranted.
Key Design Considerations
1. State Management
Dapr uses a key-value store under the hood. Waldo recommends:
- Avoiding large serialized lists.
- Partitioning data to support fine-grained access.
- Caching small frequently accessed values for performance.
2. Actor Identity
Each actor has a string-based ID. Waldo advises:
- Use unique IDs (GUIDs) for games and players.
- Share IDs across related actors when appropriate.
- Consider singleton actors (e.g., leaderboards) sparingly and with care.
3. Turn-Based Processing
Dapr actors process messages in a non-reentrant, turn-based loop. Waldo cautioned against long-running operations and encouraged background threads for high-frequency tasks (e.g., Tetris game loops), while respecting thread safety.
4. Data Extraction
Dapr does not natively support querying active actors. Developers should plan ahead by:
- Tracking actor IDs externally.
- Leveraging pub/sub for status updates.
- Designing with downstream push instead of upstream pull models.
Looking Ahead: Pub/Sub for Actors and Agentic Workflows
Waldo hinted at exciting features in the pipeline:
- Pub/Sub support for actors, allowing them to activate in response to messages.
- A new agentic workflow framework (coming in Dapr 1.16), enhancing declarative, actor-based automation.
Conclusion
Whit Waldo’s talk demystified actor-based development with Dapr, grounding abstract concepts in real-world software design. His key message: use Dapr actors judiciously, with a focus on clear domain boundaries, autonomous behavior, and performance-conscious design.
A sample of his Tetris application will soon be published in the .NET Dapr repository, offering a valuable resource for developers ready to explore actor-based architecture with confidence.
Key Takeaway:
Actors aren’t just about managing state—they’re about modeling behavior. Design them to do something, not just store something.
