Durable Task: When Processes Need Step Memory

Microsoft published an analysis on the .NET blog Durable Task in the Real World.

The authors describe five practical scenarios where durable execution is justified, as well as cases where it only adds complexity.

A separate section is dedicated to AI agents.

My takeaway is this rule: durable execution pays off when a business process outlives a single request and a lost step costs money. In other cases, a queue and an idempotent handler are enough.

Durable Task is Microsoft's open-source framework, on which Azure Durable Functions are built.

The developer describes the process in regular C# code: call a service, wait for the response, then call the next one.

The framework records the result of each completed step in its history. Suppose the process failed at the fourth step.

After a restart, the orchestrator rereads the history (this mechanism is called replay), inserts the saved results of the first three steps, and continues from the fourth.

The wait may last for days: a timer or external event is stored in the database while the thread remains free. This comes at a cost.

Orchestrator code must be deterministic: it must not call `DateTime.Now`, generate a `Guid`, or make direct HTTP requests.

The developer moves external calls into activities and obtains time and random values through the framework API. A team that does not know these rules will encounter bugs that reproduce only during replay.

Consider an order that passes through five systems: the website, 1C, the warehouse, the delivery service, and EDI. Assume each system has 99% availability.

The order then completes the chain without failure with a probability of 0.99⁵, or about 95%.

With 2,000 orders per day, approximately 100 will get stuck somewhere in the middle.

Companies usually fill this gap with a status table, a cron retry script, and a manager who manually searches for lost orders each morning.

The result is custom-built durable execution without guarantees or tests, whose design is known by only one developer.

### Processes that wait for a person Examples: contract approval, supplier onboarding, and document signing in EDI.

The process sends a document, waits three days, escalates to a manager on timeout, and continues after signing.

With a queue, this process becomes a state machine spread across five tables. In an orchestrator, it takes a few dozen lines of sequential code. ### Sagas with compensation

The warehouse reserved the item, the payment failed, and the reservation must be released.

The orchestrator stores a list of completed steps and runs compensations in reverse order.

Without this, phantom reservations accumulate in the warehouse: the item is physically on the shelf, but cannot be sold. ###

Parallel batch processing Suppose you need to enrich 50,000 item cards in Pimcore or Akeneo using an LLM.

The orchestrator splits them into batches, runs them in parallel (fan-out), and combines the results (fan-in).

If the model fails or the quota runs out on item card 30,000, processing will continue from the point of failure.

Without an orchestrator, the tokens paid for the first 30,000 item cards would have to be spent a second time. ### AI agents

An agent works in a loop: the model selects a tool, receives the result, and decides what to do next.

Sometimes an agent stops and waits for human approval.

Each iteration costs tokens and may have a side effect.

Suppose the agent fails on the twelfth call out of fifteen.

Restarting from scratch would pay for eleven calls again.

In addition, the client may receive an email twice, and a duplicate document may appear in 1C. Durable execution saves the result of every model and tool call, so after recovery the agent continues from the last step.

Short, idempotent requests that complete within seconds are handled by a retry policy. For the flow “message from Apache Kafka → database record”

An orchestrator is unnecessary too: Kafka stores the offset, and a second source of truth would only complicate debugging.

If 1C exchange already runs through an ESB with guaranteed delivery, such as Datareon, MuleSoft, or Talend, duplicating these guarantees with an orchestrator is pointless.

There is also an operational risk that teams often overlook at the start: versioning. Imagine that 400 process instances are waiting for signatures while you change the orchestrator code.

During replay, the old history will not match the new code, and the processes will fail.

The versioning strategy must be planned before the first release.