Control Loops

The pattern: observe current state, compare to desired state, take action to reduce the difference, repeat forever. Every K8s controller works this way. Every IaC tool works this way. Thermostats work this way. BGP convergence works this way. The loop is the abstraction — once you see it, you see it everywhere.

The trade-off pair: imperative scripts (you tell the system the exact sequence — fragile to partial failures) vs. control loops (you declare desired state, the loop converges — eventually consistent, self-healing, but harder to reason about timing). Control loops trade explicitness for resilience: you don’t always know when the system will converge, but you know it will. The cost is operational opacity (“why hasn’t it reconciled yet?”) and the discipline of writing idempotent actions, since the loop will re-run them.

[Deepen this entry when first hit in Phase 7. This is one of the most load-bearing patterns in the whole library — it shows up at every layer from Year 1 to Year 5.]

Related patterns

• state-vs-computation — control loops are the bridge: desired state stored, computation drives it toward observed.
• mediation — the API server is both mediator and the substrate the loop reads/writes.
• layering-and-abstraction — controllers stack: each layer’s “actuator” is the next layer’s “API.”
• idempotency — non-negotiable for any action a loop will retry.
• eventual-consistency — control loops are eventual consistency made operational.
• declarative-vs-imperative-infrastructure — declarative IaC requires a control loop to actuate.
• gitops — Argo CD is a control loop pointed at a Git repo.
• First touched: Year 1 Phase 7: Kubernetes + GitOps.
• Deepened in: Year 2 Phase 9: IaC Patterns (Terraform reconcile, Crossplane).
• Project where it lives: basecamp (Argo CD reconciles every tier).