Modern distributed applications frequently execute long-running business processes that span multiple services, external APIs, message queues, and databases. Examples include order processing, payment workflows, document approval systems, data synchronization, and AI agent orchestration. These workflows must remain reliable even when individual services fail or infrastructure experiences temporary outages.
This is where durable execution frameworks become valuable. They provide mechanisms for checkpointing workflow state, retrying failed operations, recovering from crashes, and coordinating distributed processes without requiring developers to implement these capabilities manually.
In this article, you'll learn the core concepts of durable execution, compare popular approaches available to .NET developers, and understand how to choose the right framework for different distributed application scenarios.
Note: This article compares architectural approaches rather than ranking frameworks. The most appropriate choice depends on application requirements, operational constraints, and deployment environments.
What Is Durable Execution?
Durable execution allows a workflow to continue reliably despite failures.
Traditional execution:
Start
|
Step 1
|
Step 2
|
Application Crash
|
Workflow Lost
Durable execution:
Start
|
Step 1
|
Checkpoint
|
Step 2
|
Crash
|
Resume From Checkpoint
Instead of restarting from the beginning, the workflow resumes from its last persisted state.
Why Durable Workflows Matter
Many enterprise processes involve multiple systems.
Examples include:
Payment processing
Order fulfillment
Invoice generation
Employee onboarding
Document approval
AI agent workflows
Data import pipelines
These operations may run for several minutes—or even hours—and must survive application restarts and temporary infrastructure failures.
Typical Durable Architecture
A common workflow architecture looks like this:
Client
|
Workflow Engine
|
-------------------------
| Database |
| Message Broker |
| External Services |
-------------------------
The workflow engine coordinates execution while persisting state between steps.
Core Durable Execution Features
Most workflow frameworks provide:
| Feature | Purpose |
|---|
| State Persistence | Resume after failures |
| Automatic Retries | Recover from transient errors |
| Checkpointing | Save workflow progress |
| Scheduling | Delay future execution |
| Timeout Handling | Detect stalled operations |
| Compensation | Reverse completed actions |
| Monitoring | Observe workflow status |
These capabilities reduce the amount of custom reliability code developers need to write.
Common Durable Execution Approaches
Several approaches are available within the .NET ecosystem.
| Approach | Typical Use Case |
|---|
| Azure Durable Functions | Serverless workflows |
| Dapr Workflows | Cloud-native microservices |
| Temporal | Complex distributed workflows |
| Workflow Core | Self-hosted .NET applications |
| Custom State Machines | Simple business processes |
Each approach balances flexibility, operational complexity, and infrastructure requirements differently.
Azure Durable Functions
Azure Durable Functions extend Azure Functions with durable orchestration capabilities.
Typical architecture:
HTTP Request
|
Durable Function
|
Activities
|
Storage
Strengths include:
Serverless execution
Automatic checkpointing
Timer support
Event-driven workflows
This approach is particularly suitable for Azure-centric solutions.
Dapr Workflows
Dapr provides workflow capabilities for cloud-native applications.
Architecture:
Application
|
Dapr Sidecar
|
Workflow Runtime
Advantages include:
Applications remain relatively independent of specific cloud providers.
Temporal
Temporal is a workflow orchestration platform designed for highly reliable distributed systems.
Typical workflow:
Workflow
|
Activities
|
Persistent History
Temporal emphasizes durable execution, automatic retries, and long-running workflow management.
Workflow Core
Workflow Core is an open-source .NET workflow engine.
Example workflow:
Start
|
Approval
|
Notification
|
Finish
It is often used for business process automation inside self-hosted applications.
State Persistence
Workflow state should be stored outside application memory.
Workflow
|
Checkpoint
|
Database
Persistent storage enables workflow recovery after application restarts or infrastructure failures.
Retry Strategies
Transient failures should not immediately terminate workflows.
Typical retry flow:
Failure
|
Retry
|
Retry
|
Success
Retry policies should define:
Maximum attempts
Delay interval
Backoff strategy
Failure handling
Avoid infinite retry loops.
Compensation Workflows
Not every workflow can simply retry.
Example:
Create Order
|
Reserve Inventory
|
Payment Failed
|
Release Inventory
Compensation actions reverse completed steps when later operations fail.
This approach differs from traditional database rollbacks because multiple distributed systems may already have committed changes.
Example Workflow Service
A simplified abstraction:
public interface IWorkflowService
{
Task StartAsync(Guid workflowId);
Task ResumeAsync(Guid workflowId);
}
Business logic remains separate from the workflow engine implementation.
Observability
Workflow execution should generate telemetry.
Monitor:
Workflow duration
Active workflows
Retry count
Failed activities
Queue length
Timeout events
Observability simplifies troubleshooting in distributed environments.
Security Considerations
Workflow engines often coordinate sensitive business operations.
Recommended practices:
Authenticate workflow requests.
Authorize workflow execution.
Encrypt persisted state.
Audit workflow transitions.
Protect workflow endpoints.
Validate external events.
Security should apply throughout the workflow lifecycle.
Production Best Practices
| Practice | Benefit |
|---|
| Persist workflow state | Reliable recovery |
| Separate workflow logic | Easier maintenance |
| Use retry policies | Improved resilience |
| Implement compensation | Safe failure handling |
| Monitor workflow health | Faster troubleshooting |
| Keep activities idempotent | Reliable retries |
| Test failure scenarios | Higher confidence |
Common Mistakes
| Mistake | Better Approach |
|---|
| Long-running HTTP requests | Use durable workflows |
| Keeping workflow state in memory | Persist state externally |
| Infinite retries | Define retry limits |
| Ignoring compensation | Reverse completed operations when necessary |
| Mixing business logic with orchestration | Separate responsibilities |
| No monitoring | Track workflow metrics continuously |
Troubleshooting
Workflow does not resume
Verify:
State persistence
Storage availability
Workflow identifiers
Recovery configuration
Duplicate activity execution
Check:
Idempotency
Retry configuration
Compensation logic
Slow workflow execution
Review:
External dependencies
Queue processing
Database performance
Activity duration
High failure rates
Investigate:
Network connectivity
Authentication
External APIs
Timeout settings
Durable Framework Comparison
| Feature | Azure Durable Functions | Dapr Workflows | Temporal | Workflow Core |
|---|
| Serverless Support | Excellent | Moderate | Moderate | No |
| Cloud Portability | Moderate | Excellent | Excellent | Excellent |
| Long-Running Workflows | Yes | Yes | Yes | Yes |
| Automatic Retries | Yes | Yes | Yes | Configurable |
| Checkpointing | Yes | Yes | Yes | Yes |
| Self-Hosted Option | Limited | Yes | Yes | Yes |
Rather than searching for a universally "best" framework, choose the one that aligns with your deployment model and operational requirements.
Frequently Asked Questions
What is durable execution?
Durable execution allows workflows to survive application crashes, restarts, and temporary infrastructure failures by persisting state and resuming from checkpoints.
Why not implement retries manually?
Simple retries are manageable, but long-running distributed workflows require state persistence, scheduling, compensation, and monitoring that durable frameworks provide consistently.
Are durable workflows only for microservices?
No. Monolithic applications, background processing systems, and serverless applications can also benefit from durable execution.
What is the difference between retries and compensation?
Retries attempt the same operation again after a failure. Compensation performs corrective actions to undo previously completed steps when the workflow cannot continue successfully.
Should every business process use a workflow engine?
Not necessarily. Short, synchronous operations may not require durable execution. Workflow engines provide the greatest value for long-running, distributed, or failure-prone business processes.
Conclusion
Durable execution frameworks simplify one of the most challenging aspects of distributed application development: maintaining reliable long-running workflows across multiple systems. By providing state persistence, retries, checkpointing, scheduling, and compensation mechanisms, these frameworks reduce operational complexity while improving application resilience.
Whether you choose Azure Durable Functions, Dapr Workflows, Temporal, Workflow Core, or another orchestration platform, the key is selecting a solution that matches your application's deployment model, scalability requirements, and operational goals. A well-designed durable workflow architecture enables distributed .NET applications to recover gracefully from failures while delivering reliable business processes at scale.