Durable Orchestrators and Activity Functions

Durable Functions is an extension of Azure Functions that enables stateful, long-running workflows in a serverless environment. The two primary building blocks are orchestrator functions and activity functions. Orchestrator functions define the workflow logic using deterministic code, while activity functions perform the actual work (e.g., calling external APIs, processing data). The orchestrator schedules and monitors activities, handling retries, timeouts, and fan-out/fan-in patterns. The key innovation is that orchestrators are replay-based: they execute multiple times, but only the first execution does real work—subsequent replays reconstruct state from persisted history.

When an orchestrator function runs, it writes each action (e.g., calling an activity, creating a timer) to a durable storage queue (Azure Storage queues or Service Bus). The orchestrator then yields execution. When a response arrives (e.g., activity result), the orchestrator is re-executed from the beginning. However, it replays all previous history from the durable store, skipping any already-completed actions. This ensures deterministic behavior: the orchestrator always produces the same sequence of actions given the same input. The replay happens transparently; the developer writes code that looks synchronous, but under the hood, it's asynchronous and replay-based.

To create a Durable Functions app in VS Code:

func init MyDurableApp --worker-runtime dotnet
cd MyDurableApp
func new --template DurableFunctionsOrchestration --name MyOrchestrator

To verify orchestration status using Azure Functions Core Tools:

func durable get-instances --task-hub-name MyTaskHub
func durable get-history --id <instanceId>

In the Azure Portal, navigate to the function app, select 'Durable Functions' under 'Functions'. You can monitor instances, replay history, and raise events.

Orchestrator code must be deterministic because it replays. Common pitfalls: - DateTime.Now: Use context.CurrentUtcDateTime. - Random: Generate random numbers outside the orchestrator and pass as input. - Network calls: Use activity functions for any I/O. - Binding: Only orchestration trigger binding allowed inside orchestrator. - Async: Must use await on context methods; Task.Wait() is prohibited.

Enable Application Insights for detailed logs. Orchestration replay events are logged with ReplayCount. You can set logLevel to Debug to see replay details. Use durable CLI commands to list instances and purge history.

A large e-commerce company uses Durable Functions to process orders. The orchestrator calls activities for payment validation, inventory check, shipping label generation, and email notification. Each activity is a separate function that can scale independently. The orchestrator handles retries if payment fails (e.g., retry with exponential backoff up to 3 times). If inventory is insufficient, the orchestrator compensates by cancelling the order and notifying the customer. In production, they run on the Premium plan to avoid cold starts and allow longer execution times. They configured the task hub name to be unique per deployment slot to isolate test and production traffic. Performance: they handle 500 orders per second with an average orchestration duration of 30 seconds. Monitoring via Application Insights revealed that most failures were due to timeout in the shipping API; they increased the activity timeout to 2 minutes.

A manufacturing company updates firmware on thousands of IoT devices. The orchestrator fans out to activity functions that send update commands to device batches. Each activity waits for device acknowledgment. The orchestrator uses a durable timer to enforce a 24-hour window for the update. If a device fails, the orchestrator logs the failure and continues. After all devices are processed, a final activity generates a report. They use the Netherite storage provider for higher throughput. Misconfiguration: initially, they set the control queue visibility timeout too low (1 minute), causing duplicate orchestrator executions. They increased it to 10 minutes. They also had to partition the task hub to avoid throttling.