Why This Matters
In Chapter 9, the supervisor fired all workers at once. That works when tasks are independent, but real work has dependencies. You cannot write tests until the implementation exists. You cannot update documentation until the API is finalized. Dispatching dependent tasks in parallel leads to workers operating on stale or nonexistent inputs.
A scheduler solves this. It models tasks and their dependencies as a directed acyclic graph (DAG), determines which tasks are ready to run, dispatches them in parallel batches, and advances to the next batch when the current one completes. This is the same pattern used by build systems (Make, Bazel), CI pipelines (GitHub Actions), and workflow engines (Airflow).
What You Will Build
A Scheduler class that takes a set of tasks with declared dependencies, computes execution order using topological sort, dispatches independent tasks in parallel, and handles task completion, failure, and deadlock detection.
Story Mode for this chapter is coming soon
We are crafting a fun, code-free explanation with metaphors and interactive mini-games. In the meantime, switch to Builder Mode to start learning.
What's Next
You have a scheduler that can run tasks in dependency order with controlled parallelism. But the scheduler auto-executes everything. Some tasks — modifying production configs, deleting files, deploying to staging — need human review before they proceed.
In Chapter 11, you will build a review queue that gates critical tasks behind human approval. The scheduler dispatches the task, but instead of auto-executing, it parks the task in a review queue and waits for a human decision.