Skip to content

PATTERN Cited by 1 source

Belt-and-braces dependency resolution

Problem

In a rapidly evolving infrastructure, circular dependencies in startup ordering can re-emerge at any time — new service versions introduce new implicit dependencies, configuration changes alter startup sequences, or previously-safe code paths become critical-path under new failure modes. A single mitigation strategy (either prevention-only or recovery-only) leaves a gap.

Solution

Apply two independent, complementary strategies (belt + braces):

  1. Prevention — continuously detect and eliminate circular dependencies in CI/CD before production deployment
  2. Recovery — maintain a purpose-built mechanism that can break any circular dependency at runtime, even ones that slipped past prevention

Neither alone is sufficient. Prevention catches most issues early ("early and often"), but cannot guarantee 100% coverage in a fast-evolving codebase. Recovery handles the residual risk but accepts that some failures reach production. Together they bound the failure surface from both sides.

Canonical Instance

Meta's Twine control-plane bootstrapping:

  • Belt (prevention): Belljar tests in CI/CD continuously detect critical startup dependencies, eliminating "most, if not all" dependency risks before production
  • Braces (recovery): Twine Recovery Kit (Twrko) provides "jumpstart" capability to recover control-plane services that power Twine itself

Together, Meta has "been able to successfully put the specter of circular dependencies to rest."

Distinction from Simple Redundancy

This is not N+1 redundancy (two copies of the same thing). It's two different failure-mode coverage strategies — one proactive, one reactive — that cover complementary gaps. The belt fails when detection has blind spots; the braces fail when recovery mechanisms themselves have bugs. Simultaneous failure of both is the residual risk, which is far smaller than either alone.

Seen in

Last updated · 542 distilled / 1,571 read