Durable execution

The engine records every step the code takes: each call to an activity, each timer, each message received, together with its result, appended to the execution’s history. When the program has to continue, after a crash or simply after waking up from a wait, the engine re-runs the code from the start. Whenever the code reaches a step that is already in the history, the engine hands back the recorded result instead of doing the work again, so the local variables are rebuilt and the code continues with the first new step. Microsoft describes its Durable Task Framework as event sourcing applied this way; Restate calls the history a journal.

Replay only works if the code makes the same calls in the same order every time. So workflow code must be deterministic: no reading the clock, generating random numbers or calling the network directly, only through the engine’s own APIs, with side effects moved into activities that run outside the replay path. Temporal compares the commands a replay produces with the stored history and fails the execution with a non-determinism error if they differ, so changing code while old executions are still running needs explicit versioning.

Temporal, Azure Durable Functions (built on the Durable Task Framework) and Restate all work this way. The engine still keeps its own state somewhere, for example Temporal in PostgreSQL, MySQL or Cassandra, but your code no longer saves its progress by hand.