When the Dapr community first began experimenting with distributed application patterns, developers had to assemble their own workflows from individual building blocks like Pub/Sub and State Management. This “do-it-yourself” approach worked to a point, but it came with fragility and operational overhead.
As Yaron Schneider, Dapr co-author, explains:
“Before that, users were simply stitching their workflows together using multiple Dapr building blocks. It worked, but it wasn’t great because you had to deploy and maintain more services than you needed. Workflows really give you the option to code as if you were a monolith, but then autoscale like a microservice. So it’s the best of both worlds.”
From Building Blocks to Orchestration
Dapr developers wanted a durable way to coordinate multiple services reliably, even across failures. That required a new design approach.
Dapr already had a powerful abstraction in place for scalable, stateful computation: Dapr Actors. Actors are long-running, stateful functions that have built-in concurrency and are extremely compute-efficient. Actors could run activities with their own state, scale down when idle, and scale back up when needed.
“We had this concept of actors… and that fit perfectly into workflow activities. Each actor was encapsulating the state of an activity, and if it’s finished, the system would essentially get back the CPU and memory. So it’s highly performant, lightweight, and reliable.”
Alongside actors, the State Management API and built-in telemetry features gave workflows persistence and visibility. This meant developers could track workflow progress, errors, and throughput through familiar tools like OpenTelemetry and Prometheus.
Inspired by Durable Functions, Reinvented for Dapr
The concept of durable execution wasn’t new—Microsoft’s Durable Functions had pioneered much of it. But Dapr took a different path by marrying that model with actors.
“We essentially took the best bits out of the durable execution engine that Microsoft had, brought it into Dapr, and massaged it to work with actors. The result was a really scalable and highly performant engine that proved itself at enterprise scale.”
This fusion gave Dapr Workflows both reliability and elasticity in a distributed setting.
Two Years of Engineering, One Durable Result
Building something that coordinates transactions, handles state across services, recovers from failures, and remains performant isn’t easy. Creating Dapr Workflows wasn’t just a design exercise—it was a long engineering journey.
“It took us two years to bring workflows to a stable state. That speaks to how hard of a distributed systems challenge this really is—coordinating multiple transactions across processes, state management, and failure recovery.”
One of the biggest hurdles was storage. Different databases had wildly different characteristics—transaction limits, latency, or throughput constraints.
Schneider recalls:
“Different databases have different storage formats, especially NoSQL vs SQL. So if you try to save JSON workflow state with Postgres or MySQL, you'd run into issues, but with MongoDB and Redis, it works fine. We had to design a model that works consistently across these differences.”
The breakthrough came with a hybrid model that separated execution history from workflow scheduling. This shift made autoscaling and consistency possible across environments, from Kubernetes clusters to standalone VMs.
Community and Collaboration
The project was a joint effort between Microsoft, Diagrid, and the broader open-source community.
“We literally couldn’t have done it without the people who took a bet on early versions and put them into production even before we said it was ready.”
That feedback loop accelerated development and helped refine the model into something resilient at scale.
Dapr’s journey continued with community support and institutional backing. The project graduated from the CNCF in November 2024, a hallmark of both maturity and community trust.
By early 2025, Dapr had reached v1.15, which marked the stabilization of workflows as a core building block API.
Enterprise Scale and Beyond
Today, Dapr Workflows are running at astonishing levels of throughput. Some users like Derivco or Tempestive execute hundreds of millions of transactions per day, including financial institutions handling unpredictable transaction volumes.
But Schneider emphasizes there’s more to do:
“We are investing a lot in improving performance—making workflows extremely fast, low latency, and high throughput. We’re also working on troubleshooting guides so developers can understand why a workflow didn’t complete and how to fix it.”
Dapr Workflows today is a versatile, production-grade orchestration runtime:
- Stateful workflows with activities, child workflows, timers, and event triggers.
- Event-sourced execution, enabling replayability for durability.
- Scalability through actors deployed across nodes, with load-balancing and parallel execution.
- Language support through SDKs in Python, .NET, JavaScript, Go, and Java, enabling polyglot language orchestration.
Workflows as the Foundation for Agents
One of the more intriguing outcomes of Dapr Workflows has been its role as the foundation for Dapr Agents, the agentic framework. Early on, Dapr Agents interacted directly with actors, but the team quickly realized this approach was too low-level and error-prone. As Yaron Schneider recalls:
“In the very early days of the DaprAgents project, we had a model where the agents were using actors directly, but then we figured out together with Roberto [Rodriguez] from Nvidia that it just makes more sense to layer on top of workflows.”
That insight became pivotal. Workflows already encapsulated the complexity of actors—durability, state management, scaling—while offering developers a safer, higher-level programming model.
“Today, people who are new to Dapr and asking if they should be using actors, we basically say look, you are better off using workflows because they encapsulate actors and they do the right thing. It’s easy to shoot yourself in the foot with actors when having dependency graphs. They are powerful, but with great power comes great responsibility… Workflows use actors behind the scenes and give you a much nicer programming model.”
By building on workflows, agents inherit a foundation that ensures durable execution, orchestration, and scalability. This makes it possible for AI-driven components such as reasoning engines or task-oriented agents to coordinate reliably across distributed systems. In other words, without workflows, the agentic layer would lack the durability and orchestration guarantees needed to function at scale.
How Dapr Workflows Compares
While other workflow engines like Temporal or Orkes Conductor exist, Dapr stands apart in key ways:
- Code first and developer-friendly, which means you can use the development tools of your choice.
- Vendor neutrality, thanks to CNCF governance—no lock-in, open contributions.
- Infrastructure flexibility, letting users bring their own databases and tooling.
- Architectural flexibility, letting users combine orchestration and choreography, where other solutions force orchestration.
“Vendor neutrality is really big for most enterprises. Dapr workflows are the only vendor-neutral durable execution engine out there.”
For enterprise use cases, Diagrid Catalyst adds features like centralized management, auditing on command, workflow vizualization, and the ability to “bring your own database” so that data stays within compliance policies. This flexibility is critical for organizations running across cloud, on-prem, and hybrid environments without the risk of vendor lock-in.
Based on clear enterprise requirements, Dapr Workflows emerged through years of design, testing, and collaboration. By combining the actor model with durable execution concepts, the team built a solution that balances reliability, performance, and flexibility, and can handle scale.
As Schneider reflects:
“Workflows let you code like a monolith, but scale like a microservice. They encapsulate the power of actors without the pitfalls, giving developers a code-first programming model. And that’s why adoption has taken off.”
