Batch orchestration is not durable execution
Constantly conflated. The tell is the time axis.
Lesson 03 of 06 · 6 min
DAG orchestrators and durable execution engines get discussed as if they were competitors. They solve different problems, and picking the wrong one produces the worst of both.
| DAG / batch orchestration | Durable execution | |
|---|---|---|
| Unit of work | A task, or an asset materialization | A step in a program |
| Time model | Scheduled intervals, backfill over a date axis | Event-driven, one execution per business entity |
| Control flow | Declared upfront as a graph | Arbitrary imperative code, including data-dependent loops |
| Cardinality | Tens of runs a day over big data | Millions of concurrent executions over single entities |
| Waiting | Sensors that poll | Durable timers, zero compute while waiting |
| Correctness concern | Idempotent tasks so backfill is safe | Determinism of orchestration, idempotency of steps |
The diagnostic: if your tool's first question is "which day's data is this run for," it is a batch orchestrator. If its first question is "which invoice is this execution about," it is a durable execution engine.
A team runs per-invoice dunning as scheduled DAG tasks. Each night a job scans for overdue invoices and advances them. Reminders occasionally send twice, and nobody can answer "what happened to invoice 4471."
The rest of this lesson unlocks when you commit above.