Data & architecture

Data orchestration: how data pipelines get scheduled, retried, and rerun

The finance dashboard refreshes every morning at 6am as expected. However, the currency conversion process began before the data extraction process finished loading data into the data warehouse. As a result, the currency conversion process used a combination of data from yesterday and no data at all.

Nobody touched a line of code.

The job executed at the time specified in the cron entry. This caused an issue because the process relied on a fixed schedule rather than the availability of the data.

Data orchestration coordinates the steps in a data pipeline-ingestion, transformation, and loading-so tasks execute in the correct sequence. It ensures tasks wait for actual dependencies instead of relying on a predetermined schedule, automatically retries after common failures, and allows for reprocessing of data from past periods without manual intervention.

What data orchestration actually coordinates

Data orchestration is the system that manages the timing and sequence of pipeline steps. It determines the dependencies for each task and handles the response to any failures. This layer operates above individual jobs, extraction scripts, transformation logic, and loading steps to manage them as a single process.

The orchestrator does not perform data processing tasks itself.

It does not extract rows from a source system or perform SQL transformations. Its function is sequencing. It runs the extract, verifies that it completed without errors, and triggers the subsequent transformation. It then starts the load process and prevents further actions until each step in the sequence has finished successfully.

When a fixed schedule is no longer sufficient

Most pipelines begin with a schedule. A job might run at 2am, and another at 6am, which works well initially when there are few jobs and timing conflicts are uncommon. Problems arise when one job needs another to finish before it can start, because a schedule relies on elapsed time and doesn't know if a previous step completed successfully.

This scenario occurs when a downstream job starts at its scheduled time while an upstream job is late or has failed without an alert. A list of start times is not a reliable schedule when you add more sources and transformation steps. The schedule becomes an estimate based on how long upstream processes typically take.

View dependencies as a graph instead of a list

The fix most orchestration tools reach for is a directed acyclic graph, or DAG: each task is a node, each dependency is an edge, and a task only starts once everything feeding into it has finished successfully. Airflow, Dagster, and Prefect all use some version of this, usually defined in Python, so the dependency structure is version-controlled and reviewable like any other code.

Writing the graph out explicitly also surfaces problems a schedule hides. If two teams have each built a job that depends on the same upstream table, that dependency now sits in one place, not scattered across two people's private assumptions about run times, and a change to the upstream job shows up as a change to a shared graph rather than a surprise two steps downstream.

Retries and error management

Pipelines often fail because of routine issues like API timeouts, network drops, or warehouse concurrency limits. These events do not indicate that the pipeline is broken. Instead, they suggest that the next attempt will likely succeed. Orchestrators manage these situations using configurable retries and backoff delays. This ensures that transient faults are retried several times before an alert is sent to a technician.

You must also consider what occurs when retries are exhausted. A failed task should stop only the specific branch of the graph that depends on it rather than the entire run. The system should generate an alert containing enough context, such as the specific task, run, and error, for a person to take action without having to search through extensive logs.

Backfills: rerunning history on purpose

Logic changes.

When a transformation requires a bug fix, a new column is added, or a source system schema changes, you must reprocess the last three months of output using the updated logic. This process is called a backfill. It is a primary reason to use a dedicated orchestrator instead of a collection of scripts.

A proper orchestration tool allows you to rerun a pipeline across a date range as a standard operation. This process follows the same dependency graph and retry behaviour as a normal run. It replaces the practice of manually looping a script over a list of dates and assuming the execution order will not cause issues.

Data-aware scheduling

Recent changes in orchestration tools allow data to trigger work instead of schedules. Transformations run after a file arrives. These tools use sensors or events to monitor for new files, table updates, or the completion of upstream tasks.

Dagster uses software-defined assets and Airflow uses dataset-aware scheduling to manage dependencies. In both systems, a downstream job depends on a specific dataset. The job runs automatically whenever that dataset updates. This approach eliminates the type of stale data issues mentioned in the first example.

Choosing between Airflow, Dagster, and Prefect

Airflow is the established industry standard. It is a mature, task-oriented platform with a large ecosystem of integrations. This tool is appropriate for teams that organise work into scheduled tasks and require a system with extensive documentation and a large pool of experienced users.

Dagster organises pipelines around data assets rather than the tasks that create them. This approach works for teams that require data lineage and testing to be integrated with the schedule definition. Prefect is a lighter, Python-native option that requires less infrastructure. It is suitable for smaller teams that need orchestration without managing a cluster.

None of these three options is a universal solution. You should choose based on whether your team focuses on tasks or data assets, and the amount of operational overhead you are prepared to manage.

Getting the sequencing right before picking a tool

The data you supply matters more than the particular tool you choose. An orchestrator simply follows the dependency graph you define. Start by pinpointing which jobs rely on others, figuring out how to safely retry each job, and deciding which jobs need a backfill when the logic changes.

We usually start with that mapping, because adding a scheduler to pipelines that have not been fully traced only speeds up the same stale-data issue. We create a data foundation built for AI with the dependency structure made explicit from the beginning, so orchestration coordinates a pipeline your team can understand.

Theory comes first. If you wish to apply these methods to your own data, our data consultancy can assist you in moving from the initial concept to a production environment.

Every pipeline's runbook must contain retry and rerun rules. The guide to writing data pipeline documentation includes a section covering these rules.

Frequently asked questions

What is data orchestration?

Data orchestration automatically coordinates the steps in a data pipeline, including ingestion, transformation, and loading, to ensure they run in the correct order. It manages dependencies based on actual relationships between tasks instead of a predetermined schedule, and it automatically recovers from common failures. Tools such as Airflow, Dagster, and Prefect achieve this by using a dependency graph defined in code.

Data orchestration vs ETL: what's the difference?

ETL denotes the specific tasks of extracting, transforming, and loading data. Data orchestration is the management layer that sets the timing and order of these ETL steps, and also handles responses to any failures. Although an ETL job can operate on its own, an orchestrator is needed to ensure it runs reliably alongside other processes at scale.

Data orchestration vs data pipeline: what's the difference?

A data pipeline is the series of steps that move and transform data from a source to a destination. Data orchestration is the layer that schedules and coordinates those pipelines. It handles dependencies, retries, and backfills across multiple processes. The pipeline reflects the actual work being performed, while the orchestrator makes sure the work happens at the correct time.

What is orchestration in Azure Data Factory?

Azure Data Factory orchestration links activities and pipelines using specific dependencies. This ensures that a copy activity, a transformation, and a subsequent pipeline run in order and only advance if the previous step finishes successfully. Orchestration includes managing scheduled triggers, conditional logic, and retry settings within the Data Factory pipeline interface.

What are the best data orchestration tools?

Apache Airflow, Dagster, and Prefect are the three most common tools in this category. Each is open source and provides a managed cloud version. Airflow has the largest ecosystem and uses a task-oriented model. Dagster focuses on data assets and lineage. Prefect is the easiest option for small teams to implement. Choosing among them depends on your current technology stack and whether your team prefers to work with tasks or data assets.

If you want to identify where AI can help your business, Talk to us to start with a clear assessment.

Start at your core.

Tell us where your data is today and what you want AI to do. We'll come back with a straight answer on what your foundation needs and where the quickest real win is.

Talk to us