# ADR-0001: Select an Initial Workflow Orchestrator

## Status

Proposed for Chapter 3 lab review.

## Context

TuranMart needs a first orchestration layer for daily ingestion, validation, transformation, and report-refresh jobs. The first platform stage should be easy to run locally, understandable for new data engineers, compatible with later book chapters, and mature enough to discuss production reliability patterns.

## Decision

Use **Apache Airflow** for the first production-oriented orchestration layer in the TuranMart learning platform.

## Alternatives Considered

| Alternative | Why it was considered | Main reason not selected first |
|---|---|---|
| Dagster | Strong asset-centric modeling, local development experience, and software-defined assets. | The book introduces classical DAG orchestration first; Dagster can be revisited after analytics engineering concepts are established. |
| Prefect | Friendly Python workflow model and simple local experimentation. | The initial platform benefits from Airflow's broad provider ecosystem and hiring familiarity. |
| Argo Workflows | Kubernetes-native orchestration for containerized jobs. | It assumes a Kubernetes operating model that is premature for Part 1. |

## Consequences

The team accepts Airflow's DAG-based model, scheduler/webserver/metadata-database footprint, and need for disciplined task boundaries. In exchange, the team gets a mature provider ecosystem, strong documentation, widely available examples, and a clear transition path into Chapter 11, where orchestration, retries, alerts, CI/CD, and deployment workflows are covered in depth.

## Evidence Required Before Production

| Evidence item | Owner | Minimum acceptance criterion |
|---|---|---|
| Local proof of concept | Data engineering team | One ingestion task, one validation task, one transformation task, and one notification task run successfully. |
| Upgrade review | Platform owner | Supported upgrade path and rollback procedure are documented. |
| License and dependency review | Security or platform owner | License, image base, Python providers, and direct dependencies are recorded. |
| Observability check | Platform owner | Logs, task duration metrics, failure alerts, and retry behavior are visible. |

## Review Date

Revisit this decision after completing Chapter 11 and after the first realistic pipeline incident review. If the team prioritizes asset lineage and developer experience over provider breadth, Dagster should be reconsidered. If the team standardizes on Kubernetes-native execution, Argo Workflows should be reconsidered.