Your team is choosing between a hand-rolled `saga` table (`id, step, status`) and a workflow engine like Temporal for orchestrating a saga. What does the engine actually persist differently from a status column, and why does that make workflow code written for it have to be deterministic?

A flat saga table with a status column recovers a crashed saga by reading that one field and branching on it — 'status is CHARGED, so resume from create-order'. An engine like Temporal doesn't do that; it persists an append-only history of everything the workflow has done — each step it started, each step's actual result, each timer that fired — and recovers a crash by re-executing the workflow function from the very beginning, with the engine intercepting every call to a step that already completed and handing back the recorded result instead of actually running it again. The code only genuinely executes past the point it reached before the crash; everything before that is replayed against history, not redone. That's why the workflow function has to be deterministic: replay only reconstructs the same state if it makes the exact same sequence of decisions given the exact same history, so a workflow that reads Random directly, reads the wall clock directly, or does its own I/O outside the engine's calls can produce a different sequence on replay than it did the first time — and the recovered saga silently diverges from the one that actually crashed.