Airflow architecture (scheduler, webserver, executor, metadata DB) - Time & Space Complexity
We want to understand how the work done by Airflow's main parts grows as the number of tasks increases.
How does Airflow handle more tasks without slowing down too much?
Analyze the time complexity of the scheduler checking and scheduling tasks.
from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime
from time import sleep
def task_function():
pass
dag = DAG('example_dag', start_date=datetime(2024, 1, 1))
n = 10 # example number of tasks
for i in range(n):
task = PythonOperator(
task_id=f'task_{i}',
python_callable=task_function,
dag=dag
)
# Scheduler loop (simplified)
while True:
tasks_to_schedule = get_ready_tasks(dag)
for task in tasks_to_schedule:
schedule_task(task)
sleep(5)
This code shows a DAG with n tasks and a scheduler loop that checks which tasks are ready and schedules them.
Look at what repeats as the scheduler runs:
- Primary operation: Loop over all tasks to find those ready to run.
- How many times: Once per scheduler cycle, repeating continuously.
As the number of tasks (n) grows, the scheduler checks more tasks each cycle.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | Checks 10 tasks each cycle |
| 100 | Checks 100 tasks each cycle |
| 1000 | Checks 1000 tasks each cycle |
Pattern observation: The work grows directly with the number of tasks. More tasks mean more checks.
Time Complexity: O(n)
This means the scheduler's work grows linearly with the number of tasks it manages.
[X] Wrong: "The scheduler only checks a few tasks, so its work stays the same no matter how many tasks exist."
[OK] Correct: The scheduler must check all tasks to find which are ready, so more tasks mean more work each cycle.
Understanding how Airflow's scheduler scales helps you explain system behavior and design choices clearly in real projects.
"What if the scheduler used a priority queue to track ready tasks instead of checking all tasks each cycle? How would the time complexity change?"
Practice
Solution
Step 1: Understand the role of the scheduler
The scheduler checks the workflow definitions and decides the timing and order of task execution.Step 2: Differentiate from other components
The executor runs tasks, the webserver shows status, and the metadata DB stores info. Only the scheduler plans tasks.Final Answer:
Scheduler -> Option AQuick Check:
Task planning = Scheduler [OK]
- Confusing executor with scheduler
- Thinking webserver runs tasks
- Assuming metadata DB schedules tasks
Solution
Step 1: Recall the Airflow CLI command for webserver
The correct command to start the webserver is simplyairflow webserver.Step 2: Analyze other options
airflow webserver start adds an unnecessary 'start', airflow start webserver reverses the order, and airflow webserver -p adds a port flag which is valid but incomplete without specifying the port number explicitly.Final Answer:
airflow webserver -> Option DQuick Check:
Start webserver = airflow webserver [OK]
- Adding extra words like 'start'
- Reversing command order
- Incorrect or incomplete flags
Solution
Step 1: Understand metadata DB role
The metadata DB stores task states and workflow info. If it is down, Airflow components cannot read or write task status.Step 2: Impact on scheduler and executor
The scheduler depends on the metadata DB to know which tasks to schedule. Without DB access, it cannot schedule new tasks. The executor waits for tasks from the scheduler.Final Answer:
Scheduler will stop scheduling tasks -> Option BQuick Check:
Metadata DB down stops scheduler [OK]
- Thinking tasks run without DB
- Assuming webserver crashes immediately
- Believing executor ignores tasks
Solution
Step 1: Analyze symptoms
Tasks are marked scheduled in the webserver UI but are not running. This means scheduling is done but execution is not happening.Step 2: Identify responsible component
The executor runs the tasks. If tasks are scheduled but not running, the executor might be stuck or misconfigured.Final Answer:
Executor -> Option AQuick Check:
Tasks not running? Check executor [OK]
- Checking scheduler when scheduling works
- Restarting webserver unnecessarily
- Ignoring executor logs
Solution
Step 1: Understand distributed setup needs
In distributed Airflow, multiple executors and schedulers may run on different machines.Step 2: Identify shared resource for coordination
The metadata database stores task states and is the central point both scheduler and executor use to coordinate which tasks to run and their status.Step 3: Exclude other options
The webserver is for UI only, local logs are not shared, and scheduler's local cache is not accessible by executors.Final Answer:
Metadata Database -> Option CQuick Check:
Shared coordination = Metadata DB [OK]
- Thinking webserver shares task state
- Assuming local logs are shared
- Believing scheduler cache syncs executors
Ready to prove it?
Pass the test and this pattern moves unknown
