Skip to content
About
Main content
Recurring principle

Undeclared dependencies

An optimization that succeeds becomes an undeclared dependency, with leverage 1/(1 − h).

What it is

If the cache sustains hit rate h, the layer below is asked for only (1 − h)λ requests per second. Sooner or later someone will size that lower layer for exactly that smaller load. Then the cache has leverage

against the backing store. At h = 95% the leverage is 1/0.05 = 20 to 1. At h = 99% it is 1/0.01 = 100 to 1. And look at what happens at the top: a drop from h = 0.99 to h = 0.98 changes the load below from 0.01λ to 0.02λ. A one-point drop in hit rate at 99% doubles the load on the layer below.

Hit rate is leverage, and leverage is fragility. This is how an optimization quietly turns into a load-bearing dependency that appears on no dependency diagram.

From Caching › Two inequalities

The coupling in the shared-log case is subtle, so we state it plainly: retention becomes a shared contract. When someone shortens retention from 7 days to 3 to save money, they have silently reduced every consumer's maximum tolerable outage to 3 days. That is a dependency between teams with no interface to review it.

From Data Movement › Publish/subscribe

Its real product is the second-order finding. A single-component injection mostly confirms what you expected. What chaos really finds are dependencies nobody declared: the "optional" service that turns out to be on the critical path, the failover that works but takes eleven minutes, the fallback that calls the thing that is down. Would chaos still find anything if the dependency graph were accurately known? Probably yes, because the interesting failures are in timing and capacity, not in topology. That is a prediction, not a result.

From Measurement & Experimental Method › Chaos testing

Where it appears

In 7 mechanisms. Each says what the mechanism is about, then how this principle shows up there, in its own words.

Made on the same pages most often.