Durable Function

The central controller of a workflow. An orchestrator function defines the sequence and logic for executing activity functions and other sub-orchestrations. Its key characteristic is deterministic execution: the orchestrator code must produce the same result when replayed, which Durable Functions enables by using event sourcing to track history and manage replay automatically.

• Checkpointing & Replay: The runtime periodically checkpoints the orchestrator's state. If the host fails, a new instance replays the history to rebuild the current state, ensuring durability.
• Durable Context: Provides APIs (IDurableOrchestrationContext) for scheduling activities, creating timers, waiting for external events, and managing sub-orchestrations.

The stateless, executable units of work within an orchestration. Activity functions contain the actual business logic that performs tasks like calling a database, processing a file, or invoking an external API. They are designed to be idempotent where possible, as the orchestration engine may retry them in case of failure.

• Execution Guarantees: Activities are executed at least once. The orchestrator manages retries with configurable policies (e.g., exponential backoff).
• Input/Output: Receive input from and return output to the orchestrator. Their execution is tracked as part of the orchestration's event history.

A mechanism for creating delayed execution or implementing timeouts within an orchestration without blocking a thread. Created using context.CreateTimer(), durable timers are resilient to process recycling. The orchestrator function suspends and automatically resumes when the timer expires, with the state fully preserved.

• Use Cases: Implementing human approval timeouts, delaying retry attempts, scheduling future work, or polling an external system with a delay.
• Persistence: Timer schedules are durably stored, ensuring they fire even if the entire app scales to zero and restarts.

A pattern that allows an orchestration to pause and wait for asynchronous input from outside the workflow. The orchestrator uses context.WaitForExternalEvent() to listen for a named event. An external client (e.g., a human via a webhook, another system) can then raise this event to the specific orchestration instance, providing the necessary data to proceed.

• Human-in-the-Loop: Essential for workflows requiring manual approval or review.
• Async Callbacks: Enables orchestrations to interact with systems that use webhook or callback-based APIs.

An orchestrator function can call another orchestrator function as a sub-orchestration. This enables modular, hierarchical workflow design, breaking complex processes into reusable, manageable components. The parent orchestrator manages the sub-orchestration's lifecycle, including its input, output, and error handling.

• Modularity & Reuse: Encapsulate common workflow patterns into reusable sub-orchestrations.
• Scalability: Sub-orchestrations can be distributed across multiple workers. The parent can fan-out to execute many sub-orchestrations in parallel and fan-in the results.

An orchestration that runs indefinitely by design, typically using a perpetual loop. Eternal orchestrations are useful for monitoring, aggregation, or agent-like continuous processing. They are made durable by the framework's checkpointing and can be gracefully terminated via an external event.

• Pattern: while (true) { await context.CallActivityAsync(...); await context.CreateTimer(...); }
• Management: Can be started via a client binding and stopped by raising a termination event. The runtime manages their state across indefinite executions and host restarts.

The core software system that manages the execution, sequencing, and state of complex, multi-step workflows. An orchestration engine is responsible for scheduling tasks, handling failures, and maintaining workflow state, abstracting these complexities from the business logic. Durable Functions provide a managed orchestration engine on Azure.

• Centralized Control: Directs the flow of a workflow, unlike decentralized choreography.
• State Management: Persists the progress and context of a running workflow.
• Failure Handling: Implements retry policies, timeouts, and compensation logic.

A computational model used to define and manage workflow logic. A state machine explicitly models a finite number of states, the valid transitions between them, and the actions that occur during transitions. This pattern is foundational for implementing reliable orchestrators.

• Deterministic Execution: The next state is determined solely by the current state and the incoming event.
• Visual Modeling: Often represented with diagrams, making complex workflows easier to design and reason about.
• Durable Functions: Use an implicit state machine to manage the lifecycle of an orchestration, automatically checkpointing state.

A workflow or transaction that executes over an extended period—from minutes to days or longer. Managing long-running processes requires solutions for durability, as the process must survive server restarts, network failures, and scaling events.

• Durability Requirement: State must be persisted to external storage, not held in volatile memory.
• Human-in-the-Loop: May involve waiting for external events like approvals or sensor data.
• Serverless Challenge: Traditional serverless functions are stateless and short-lived; frameworks like Durable Functions are designed specifically to overcome this limitation.

The critical mechanism that enables durability and replay in orchestration frameworks. Checkpointing involves periodically saving the complete state of an executing workflow to a durable store (like Azure Storage). If the host process fails, a new instance can reload the last checkpoint and resume execution.

• Fault Tolerance: The cornerstone of recovery from hardware or software failures.
• Automatic in Durable Functions: The framework handles checkpointing transparently, often at each await point in the orchestrator code.
• Event Sourcing Link: Checkpoints are often implemented by persisting a log of events that can be replayed to reconstruct state.

A design pattern for managing data consistency across multiple services in a distributed transaction. A Saga breaks a transaction into a sequence of local transactions, each with a corresponding compensating transaction to undo its effects if a later step fails.

• Eventual Consistency: Achieves consistency without distributed locks, accepting temporary inconsistency.
• Orchestration vs. Choreography: Can be implemented with a central orchestrator (like Durable Functions) or through event-based choreography.
• Compensation Logic: Critical for implementing rollback, such as issuing a refund after a payment service succeeds but inventory allocation fails.