The "Big Red Button" Problem
Imagine you are setting up a new apartment. You cannot hang pictures before the walls are built, and you cannot build the walls before the foundation is poured. Infrastructure has the same constraint — some things must exist before others can be created. When your infrastructure is split across dozens of independent state files (a practice called State Sharding), you need something to manage that ordering automatically.
We previously discussed State Sharding — splitting your infrastructure into many small state files (VPC, DB, App, Redis) to reduce blast radius. Each file is independently manageable, but that independence creates a new problem: ordering. To deploy a new environment from scratch, you cannot run terraform apply 50 times in random order.
- The App fails if the Database isn't ready — it has no connection string to connect to.
- The Database fails if the Subnets aren't ready — it has no network to attach to.
- The Subnets fail if the VPC isn't ready — they have no parent network to live inside.
This chain of dependencies forms what computer scientists call a Directed Acyclic Graph (DAG) — a graph where each node (stack) points to its dependencies, and there are no circular loops. The word "acyclic" is critical: if Stack A depends on Stack B which depends on Stack A, you have a deadlock and nothing can ever be created.
You need an Orchestrator: a tool that understands this DAG and runs the applies in the exact right order, parallelizing where safe and serializing where required.
The senior insight here is that the DAG problem is not unique to Terraform — it appears in CI/CD pipelines (GitHub Actions needs:), container orchestration (Kubernetes init containers), and package managers (apt, npm). The same mental model applies everywhere: identify the dependency graph, then execute in topological order.