State machines versus long-running functions

WHAT THIS TESTS This probes whether you understand the difference between orchestration and execution, and the failure modes of cramming durable, long-waiting workflow logic into one function.

A GOOD ANSWER COVERS A state machine externalizes the workflow's state in a managed service. Steps can be sequential or parallel, and the machine can pause for a long time, including waiting on human approval via a callback token, without any compute running or being billed. It provides declarative retries with backoff, catch-and-fallback error handling, and a visual execution history that makes auditing and debugging straightforward. Each step is a small, independently testable function. By contrast, a single long-running function is bounded by a maximum execution timeout, so it cannot wait days for human input; it bills for the entire idle wait; if it crashes mid-process all in-memory state is lost with no resumability; and the branching, retry, and parallelism logic becomes brittle hand-rolled code. The state machine also decouples steps so they scale and fail independently.

COMMON WRONG ANSWERS Saying the function can just sleep until approval, ignoring timeouts and idle cost. Claiming there is no real difference. Reimplementing retries and persistence by hand instead of using the managed orchestrator. Overlooking the audit and observability value of the execution history.

LIKELY FOLLOW-UPS How does the wait-for-callback pattern handle human approval? What are standard versus express workflows? How is state passed between steps? What are the cost tradeoffs at very high transition volume?

ONE CONCRETE EXAMPLE A loan approval workflow runs validation and a credit check in parallel, then pauses on a manual review using a task token. A reviewer approves days later, the callback resumes the machine, and disbursement runs, all without any function idling or any custom state store, and with the full path visible in the execution history for audit.