Batch Orchestration
also called Workflow Orchestration, DAG Scheduling
Running interdependent data jobs in the right order with retries, backfills and failure handling, expressed as a dependency graph rather than a schedule.
The distinction that matters is between time-based and dependency-based execution. Cron runs a job at 02:00 and hopes its inputs are ready; an orchestrator runs a job when its inputs are actually ready. The difference shows up on the day an upstream feed is two hours late: cron produces a report from yesterday's data with today's date, silently, and the orchestrator waits or fails loudly.
The properties that separate a usable orchestrator from a scheduler: dependency-driven triggering, per-task retry with backoff, idempotent re-runs so a failed task can simply be repeated, parameterised runs by logical date so backfills are the same code as forward runs, and lineage visible enough to answer what is downstream of a failed task before you decide how urgent it is.
The design discipline underneath is idempotency. A task that appends rather than replaces will duplicate on retry, and since retries are automatic, the duplication is silent and periodic. Writing each task to replace the partition it owns is the practice that makes an orchestrated pipeline recoverable rather than fragile.
Backfill is the operation that exposes a poorly designed graph: if reprocessing six months requires manual intervention, the pipeline will not be corrected when it is found to be wrong.