The Shape of the Whole

Companion to The Shape of the System. Read that first. Roman numerals in brackets, like (XIX), point to the parent's tenets; the five laws here are named.

There are two ways to ask whether a system will hold. One of them starts from the part and works up: you make each piece correct on its own, you get the contract right at every boundary, and then you trust that well-built parts and honest hand-offs add up to a sound whole. That is the manifesto, and it is local by design. The other one starts from the whole and works down. You begin with what the entire system must never do and you decompose from there, asking how parts that are each behaving exactly as built can still combine into a failure. That is reliability engineering, and it assumes the opposite thing. Not that good parts will hold, but that something always gives, and the work is bounding what it takes with it when it does.

The two ways meet in one place, and they get there from opposite ends. It is the failures that live in the composition and in no single part. From the bottom up that is the far edge of the map, and you are walking away from it, so calling it out of scope is not negligence, it is just the honest limit of a local view, and the manifesto stops there on purpose. From the top down it is right there in the middle of the page. It is the first question you ask.

The objective does not change to meet these failures. It is the parent's, word for word: minimise what a tired engineer must hold in their head to make a correct change, subject to keeping the blast radius bounded for anything an attacker or an unlucky caller controls. The move does not change either. You push correctness out of vigilance and into structure. What changes is only the type of structure. A type makes an illegal value unrepresentable. Here the structure is a model of the composition - a dependency graph, a capacity model, a consistency contract - and it makes a bad arrangement impossible to build where you can rule it out, impossible to miss where you cannot, and bounded when it shows up anyway. Some of these failures you design out and the rest you design to contain. The graph is a type whose values are topologies. The capacity model is a type whose values are loads. The consistency contract is a type whose values are histories. They are structure in the same sense a schema is. They hold whether or not anyone remembers them, and they keep the shape of the whole somewhere a reader can go and look instead of having to reconstruct it. The structure is just a different type, and that is all of it. Externalise, don't memorise.

None of this is free, and here the cure is most often the disease. Every model is itself state, and state drifts, and a stale map of the system is worse than no map at all, because it lies to you in the one moment you reach for it. And every mechanism that enforces a property across components - a coordinator, a consensus group, a saga - manufactures the coupling, the latency, and the fresh cascades the parent spends twenty-five tenets trying to contain. So each law names four things: the failure no component owns, the model that makes it tractable, the cost the cure itself imposes, and one question to ask before you ship. Reach for the machinery of the whole only when the property is real and violating it costs more than coordinating it. None of it is free.

Draw the graph: independence is a claim, not a default

The components you call independent fail together through the substrate you forgot they share; map it, or the outage maps it for you.

Two services on separate hosts, written in different languages, owned by different teams, will feel independent right up until both of them resolve the same DNS, or read the same config service, or trust the same certificate, or sit in the same availability zone, and then the one thing underneath takes them both down in the same instant. Independence is not the resting state of a distributed system. It is a property you engineer and then verify, and common-mode failure is the bill for assuming it came for free. The shared substrate has a worst form and a funniest one. The worst is the DNS that withdraws its own routes when it cannot reach home, and then cannot be reached to undo it. The funniest is the status page served from the very thing whose outage it exists to announce. The same graph hides the other shape too, the cycle: A needs B needs C needs A, invisible from inside any one service, and a deadlock the moment they all boot cold or contend for one pool under load. The graph, not the service, is the unit of reasoning here, and the parent's bulkheads and cells (XIX) only contain this once you can already see it. This law is about seeing it.

Infra/cloud: a hundred "independent" services behind one control plane, one config store, one identity provider, where the bulkhead is real only if the pools, the zones, and the secrets are genuinely disjoint, not merely drawn in separate boxes.
Distributed: a startup cycle three services deep that deadlocks only on a cold boot with an empty cache, and so runs for years without anyone seeing it, because in daylight the cache is never empty.
Data/ML: a feature pipeline and the model that serves it both keyed to one upstream table, so a single schema change fells two systems nobody had ever written down as related.

Tension: The map is itself state, and stale state lies more confidently than no state at all (XIV, XX). A dependency diagram drawn once by hand and left to rot will reassure you in precisely the incident it was drawn to illuminate. So derive the graph, do not draw it. Generate it from traces, the service mesh, the infrastructure-as-code, and give it an owner and an expiry like anything else that can go stale (XXV). And you cannot map everything, so map the shared substrate whose joint failure is catastrophic, defer the rest, and write down which ones you deferred.

Ask yourself: What single thing, if it died this second, would take down everything I am treating as independent, and did I check that it is disjoint, or only assume it?

Lineage: normal accidents / tight coupling and interactive complexity [Perrow 1984]; common-mode failure and lined-up holes [Reason 1990]; cell isolation and blast radius [AWS 2019]; deadlock and circular wait [Coffman et al. 1971]; shared fate at scale [Hamilton 2007]; cyclic dependency and severed recovery tools [Meta 2021]; the status page that depends on the thing it reports [AWS S3 2017]

Find the loop that will not let go

The trigger that started the outage is not the thing keeping it down; a system can hold itself in the bad state long after the cause is gone.

This is the failure the parent stocks every ingredient for and never names. A metastable failure has two stable states, a healthy one and a collapsed one, plus a sustaining feedback loop that feeds the collapse its own exhaust. A latency blip trips a wave of timeouts, the timeouts fire retries, and the retries are the new load, and the load keeps the latency going, so removing the original blip does nothing whatever, because by now the system has become its own cause. The signature is hysteresis: the push that knocked you down will not lift you back up. The retry storm is the textbook case. What makes it so vicious is that the congestion sustaining it is usually the same congestion blinding the monitoring you'd reach for to find it, so you end up hunting in the dark for a fire that feeds on your attempts to get near it. Capped retries, jitter, breakers, and deadline-aware shedding (tenets V, VI, VII, XIX) are exactly the right tools. But the parent prescribes them one edge at a time, as local manners, and local manners are necessary without being sufficient. At the scale of the whole the question isn't "does this edge have a deadline" but "does the system have a way back" - a response that reduces the load that caused it, a loop gain below one, and some way to throw out work that's already past its deadline, so recovery isn't made to fight a queue full of the dead.

Distributed: a retry storm that outlives the dependency's recovery, because every client has synchronised onto the same clock and the queue is full of requests that died waiting; only shedding the backlog and scattering the herd brings the good state back.
Data/infra: a cache stampede where every miss regenerates the same hot key, the regeneration is the load that causes the next miss, and only coalescing the requests, one regeneration shared by all, breaks the wheel.
Capacity: a system serene at 70% utilisation and bistable at 85%, where one transient spike tips it into a collapse it won't climb out of until someone sheds load by hand.

Tension: The way back is itself behaviour, and behaviour you don't observe is behaviour that fails in silence (tenet XVIII). Every shed, every coalesce, every breaker trip has to announce that it fired, or you've hidden the metastable state rather than escaped it. And the cure has a floor. A system that sheds at the first tremor never reaches the throughput it was bought for. Tune the trigger to the edge of the bistable region, not to the comfortable middle.

Ask yourself: If the thing that triggered this outage vanished this second, would the system climb out on its own, or is something it's still doing holding it under?

Lineage: metastable failures [Bronson et al. 2021]; stocks, flows and feedback [Meadows 2008], system dynamics [Forrester 1961]; backoff and jitter [Brooker 2015]; saturation and queueing [Little 1961]; self-stabilisation, convergence from any state [Dijkstra 1974]; self-sustaining retry storm and blinded recovery [AWS 2021]

III

Name the invariant no service owns

Every component can be correct on its own while the system as a whole is wrong; the rule that spans them belongs to none of them until you give it a home.

The parent's defences against contradictory state are all dyadic. Parse, don't validate (tenet III) makes a value legal inside a unit; one source of truth (tenet XIV) keeps a fact honest between an owner and its derived views; name the boundary (tenet XV) makes a contract legal across a single hand-off. None of them reaches the case where service A and service B and service C are each, alone, entirely consistent, and the combination of them is illegal: the seat sold twice because two booking nodes each held a locally valid view, the account overdrawn because the debit and the limit live in different stores, the order shipped and refunded because two workflows each did the right thing in ignorance of the other. This is a distributed invariant, a rule over three or more parties that no single party can see far enough to enforce. You can't wish it into a type and you don't get it for free. You decide, out loud, where it lives. Maybe a coordinator that serialises the decision. Maybe a saga that sequences local steps and carries a compensation for each one in case a later step fails. Maybe a quorum that makes a majority agree before anyone acts. Or an honest admission that the rule is eventually consistent, paired with a reconciliation sweep that finds the violation and repairs it after the fact. What you may not do is leave it implicit, upheld only by every service happening to behave, which is the swallowed error (tenet XIII) written at the scale of the whole system.

Distributed: "a seat is sold at most once" across N nodes wants a single owner of the seat, a fenced lease (tenet IX), or a reserve-then-confirm saga, never N nodes each trusting its own local replica.
Data/infra: "these two tables always agree" across a service boundary wants one writer and one subscriber (tenet XIV), or a reconciliation job that names the drift out loud, never two writers and a hope.
Microservices: "create the order, charge the card, reserve the stock" is one business invariant wearing three services; a saga with a compensating refund and release, because a distributed transaction strung across the three is the exact coupling and cascade you were trying to avoid.

Tension: This is the law where the cure most eagerly becomes the disease. A coordinator is a fresh single point of failure and a new shared substrate (Law I); a consensus group trades availability for consistency the moment the network partitions, the CAP bargain the parent names and defers; and a saga's compensations are themselves irreversible-decision code (tenet XI) that can fail halfway. Coordination is never free, and it's often the most expensive thing in the building, so spend it only where the invariant is real and its violation costs more than the coordination does. Most of what people call invariants will tolerate eventual consistency. Keep the strong machinery for money, for safety, and anything genuinely unrepeatable.

Ask yourself: Which rule lives between these services that none of them owns, where does it live today, in a home or in a hope, and what does enforcing it cost set against what violating it costs?

Lineage: CAP, consistency under partition [Gilbert & Lynch 2002]; sagas [Garcia-Molina & Salem 1987]; life beyond distributed transactions [Helland 2007]; consensus [Lamport 1998], [Ongaro & Ousterhout 2014]; conflict-free replicated state [Shapiro et al. 2011]; fenced lease [Kleppmann 2016]

Compose the control loops on purpose

An autoscaler, a load balancer, a circuit breaker, and a cache are each a controller; wire four correct controllers together and they will fight.

The parent contains control loops, the level-triggered reconciler (tenet VIII), the breaker (tenet XIX), but it meets them one at a time. Run several in one system and their interaction becomes a behaviour that none of them specifies and none of them can see. The autoscaler removes capacity because load fell; load fell because the breaker opened; the breaker opened because the surviving instances saturated; and now the scale-down deepens the saturation that started it. Every controller did precisely its job. Put together they oscillate. Each loop was tuned alone and proven stable alone, which tells you almost nothing, because two loops that are each stable in isolation can combine into one unstable loop the instant their timescales line up, each one chasing a signal the other is busy moving. The discipline here is borrowed from control theory, not from a slogan. Know which signals each loop reads and which it writes. Keep two loops that touch the same variable off the same timescale, so the fast one settles before the slow one stirs. And where they genuinely must move the same lever, give one of them authority and make the other defer. Don't leave them to argue.

Distributed: an autoscaler and a load-shedder reading the same latency number, one adding capacity while the other rejects traffic, each erasing the other's correction.
Infra: a retry policy and a circuit breaker tuned in separate rooms, so the breaker opens and closes in a rhythm the retries themselves drive, flapping where it was meant to heal.
Frontend/edge: a client-side backoff and a server-side rate limiter whose windows resonate, the limiter's period and the clients' retry period beating against each other like two metronomes set a fraction apart.

Tension: Damping costs you speed, and a loop slow enough that it never oscillates is also a loop too slow to correct a real fault when one shows up. Designing the loops together pulls hard against locality (I) and against independent deployment, which was the whole reason they were separate controllers to begin with. You cannot pretend this one away. The only honest fix is to model the coupled system, and that is exactly the cognitive load the parent exists to spare you, so pay it only where the loops demonstrably interact. Most of them do not.

Ask yourself: When all of these controllers act at once on the same signal, do they settle, or have I only ever checked that each one is correct alone?

Lineage: feedback control and stability [Åström & Murray 2008]; control-structure hazards [Leveson 2011]; ironies of automation [Bainbridge 1983]; coupled-loop oscillation and the bullwhip [Sterman 2000]; self-stabilisation [Dijkstra 1974]

Probe the whole: green parts are not a green system

Every component reports healthy while the path through them is broken; health is a property of the route, not of the nodes.

This is the composition-level twin of the parent's observability tenet (XVIII), and it stays blind in a way that per-component monitoring can never fix. Gray failure is the state where every service's health check is green - it is up, it answers, its own dashboard is calm - and yet the request that has to cross all of them does not arrive, because the degradation is differential: bad enough to break the journey end to end, but too mild to trip any one check along the way. Each node is an honest witness to the wrong question. You cannot add green signals up into a true picture of the whole, because the failure lives in the composition of their behaviours and not in any one of them. Eight services each adding a little tail latency that is harmless alone and fatal once it stacks. A node that passes its liveness probe while quietly dropping one packet in twenty. A pipeline whose every stage reports success over an output that is wrong, because correctness was a property of the stages agreeing and no stage was watching that. The verification has to match the scale of the failure. Probe the path the way a user walks it, end to end, traced edge to edge against a budget (VI), and provoke the composition on purpose with fault injection and game days at the scope of the whole system, so the emergent failure happens in daylight with someone watching and not at three in the morning with nobody about. Component health answers "is each part alive". Only a whole-path probe answers "does the system do its job".

Distributed: a request that touches eight green services and times out in the aggregate, because each adds 40% tail latency that every local check calls fine; only an end-to-end trace against a deadline (VI) shows you the sum.
Infra: a node that sails through its liveness check while dropping 5% of packets, healthy to its own monitor and a slow poison to everything routed through it.
Data/ML: a pipeline where every stage flags success and the result is quietly wrong, because what was correct was the agreement between the stages, and no stage owned the agreement.

Tension: Whole-system probes and fault injection are themselves load and themselves risk. A game day is a controlled outage, and synthetic traffic is real traffic the system has to carry, both of which you must bound and pay for (VII, XVIII). Run the drills you will actually act on, on the routes whose failure would actually hurt, and treat the probe budget like any other thing a caller can grow without limit. An end-to-end check nobody reads is just the silent fallback (XVIII) wearing a dashboard for a disguise.

Ask yourself: Does every part report green while the route across them is red, and have I ever actually sent a request, or a fault, the whole way through?

Lineage: gray failure and differential observability [Huang et al. 2017]; chaos engineering and fault injection [Basiri et al. 2016], [Principles of Chaos 2015]; distributed tracing [Sigelman et al. 2010]; how complex systems fail [Cook 1998]

The through-line

Every law here is the parent manifesto's one move - push correctness out of human vigilance and into the structure of the system - applied where the structure can no longer be a type, a schema, or a single boundary, because the condition being kept is not a property of any part. So the structure becomes a model of the whole instead: a dependency graph, a feedback diagram, a consistency contract, a coupled-loop model, an end-to-end probe. It is structure in the same sense the parent's types and schemas are, and it keeps the shape of the whole somewhere a reader can go and consult rather than reconstruct. The graph names the shared substrate, the loop with no way back gets drawn before it closes, the invariant no service owns is given a home, the coupled controllers are designed as one, and the broken route is provoked while someone is watching. All of it comes from pushing the shape of the whole into structure the same way every other correctness condition is, rather than from reasoning about the entire system at once. Externalise, don't memorise.

And the parent's tie-breaker still governs, with one cost its scope let it hide: every cure on this page can manufacture the very failures the parent spends itself containing. A coordinator becomes a single point of failure. A consensus group trades away availability. A model left to drift lies to you in the incident. So when two pulls fight - consistency against availability, a coordinated invariant against a contained blast radius, a damped loop against a responsive one - the resolution is the one it always was. Minimise what a tired engineer must hold in their head to make a correct change, subject to a bounded blast radius, and reach for the heavy machinery of the whole only when the property is real and violating it would cost more than the coupling the cure drags in behind it.

Write for the engineer reading the map at 2am with the pager going off, knowing less than whoever drew it. Make the right model the easy one to reach for, and never make them rebuild from memory what the model could have held for them, because a wrong picture of the whole is worse than the honest absence of one.

Appendix: Sources & Influences

Like its parent, this companion invents nothing. Composition-level failure is the territory of decades of distributed-systems, control-theory, and safety-engineering work, and this page only recompresses that work into the parent's frame and vocabulary, and credits the people who found it first. Where a coinage belongs to its author it is named: "metastable failures" is Bronson and colleagues', "gray failure" is Huang and colleagues', "normal accidents" and the tight-coupling lens are Perrow's, "sagas" is Garcia-Molina and Salem's. Per-law lineage lines appear inline above.

This page also carries a debt the bibliography cannot hold. My sister, Claire, who models how whole systems fail and what it takes to keep them holding, read the manifesto and saw in one pass what I had filed as out of scope: that a book which stops at the boundary leaves the whole unspoken, and that the silence was the opening a sceptic would use against all of it. She was right, and the page exists because she said so. The principle is old, older in her trade than in mine, but the judgement that it belonged in the book was hers. I owe her more than I can put here.

Bibliography

[Åström & Murray 2008] Karl Johan Åström & Richard M. Murray, "Feedback Systems: An Introduction for Scientists and Engineers". Princeton University Press, 2008. https://www.cds.caltech.edu/~murray/amwiki/. Stability, gain, and lag in feedback control, the formal backbone of composing controllers; law IV.
[AWS 2019] Amazon Web Services, "Reducing blast radius with cell-based architectures" (re:Invent 2019, ARC411). 2019. https://www.youtube.com/watch?v=swQbA4zub20. Cell isolation as fault containment for shared substrate; laws I, V. (shared with the parent)
[AWS S3 2017] Amazon Web Services, "Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region". 2017. https://aws.amazon.com/message/41926/. The Service Health Dashboard could not report the outage because it was itself served from the failed S3 region, the purest image of common-mode coupling; law I.
[AWS 2021] Amazon Web Services, "Summary of the AWS Service Event in the Northern Virginia (US-EAST-1) Region" (December 7, 2021). 2021. https://aws.amazon.com/message/12721/. An automated scaling action triggered a self-sustaining retry storm that outlived its trigger and degraded the monitoring needed to diagnose it; laws II, V.
[Bainbridge 1983] Lisanne Bainbridge, "Ironies of Automation". Automatica 19(6), 1983. https://doi.org/10.1016/0005-1098(83)90046-8. Automated controllers create new failure modes precisely where they remove the human; law IV.
[Basiri et al. 2016] Ali Basiri, Niosha Behnam, Ruud de Rooij et al., "Chaos Engineering". IEEE Software 33(3), 2016. https://doi.org/10.1109/MS.2016.60. Provoking emergent failure deliberately, at system scope; law V.
[Bronson et al. 2021] Nathan Bronson, Abutalib Aghayev, Aleksey Charapko & Timothy Zhu, "Metastable Failures in Distributed Systems". HotOS XVIII, 2021. https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s11-bronson.pdf. The sustaining-loop and bistable-state framing, and hysteresis as the signature; law II.
[Brooker 2015] Marc Brooker, "Exponential Backoff And Jitter" (AWS Architecture Blog). 2015. https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/. De-synchronising retries so a recovering system is not immediately re-herded; law II. (shared)
[Coffman et al. 1971] E. G. Coffman, M. J. Elphick & A. Shoshani, "System Deadlocks". ACM Computing Surveys 3(2), 1971. https://doi.org/10.1145/356586.356588. The four conditions, with circular wait as a property of the dependency graph; law I. (shared)
[Cook 1998] Richard I. Cook, "How Complex Systems Fail". Cognitive Technologies Laboratory, University of Chicago, 1998. https://how.complexsystems.fail/. Systems run degraded as their normal state, and failure is emergent and multi-causal; laws II, V. (shared)
[Dijkstra 1974] Edsger W. Dijkstra, "Self-stabilizing Systems in Spite of Distributed Control". CACM 17(11), 1974. https://doi.org/10.1145/361179.361202. Convergence to a good state from any global state, the root of the return path; laws II, IV. (shared)
[Forrester 1961] Jay W. Forrester, "Industrial Dynamics". MIT Press, 1961. https://mitpress.mit.edu/. Feedback structure as the driver of system behaviour over time; law II.
[Garcia-Molina & Salem 1987] Hector Garcia-Molina & Kenneth Salem, "Sagas". ACM SIGMOD, 1987. https://doi.org/10.1145/38713.38742. Long-lived transactions as sequenced local steps with compensations; law III.
[Gilbert & Lynch 2002] Seth Gilbert & Nancy Lynch, "Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services". SIGACT News 33(2), 2002. https://doi.org/10.1145/564585.564601. The CAP trade the parent names and defers; law III. (shared)
[Hamilton 2007] James Hamilton, "On Designing and Deploying Internet-Scale Services". USENIX LISA, 2007. https://www.usenix.org/legacy/event/lisa07/tech/full_papers/hamilton/hamilton.pdf. Operational dependency and shared-fate discipline at scale; law I.
[Helland 2007] Pat Helland, "Life beyond Distributed Transactions: an Apostate's Opinion". CIDR, 2007. https://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf. Why cross-service transactions do not scale, and what to reach for instead; law III.
[Huang et al. 2017] Peng Huang, Chuanxiong Guo, Lidong Zhou, Jacob R. Lorch, Yingnong Dang, Murali Chintalapati & Randolph Yao, "Gray Failure: The Achilles' Heel of Cloud-Scale Systems". HotOS XVI, 2017. https://doi.org/10.1145/3102980.3103005. Differential observability: green parts, broken whole; law V.
[Kleppmann 2016] Martin Kleppmann, "How to do distributed locking" (fenced tokens), and "Designing Data-Intensive Applications", 2017. https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html. Enforcing a single-writer invariant across a boundary; law III. (shared)
[Lamport 1998] Leslie Lamport, "The Part-Time Parliament" (Paxos). ACM TOCS 16(2), 1998. https://doi.org/10.1145/279227.279229. Agreement among many parties as a primitive for distributed invariants; law III.
[Leveson 2011] Nancy G. Leveson, "Engineering a Safer World: Systems Thinking Applied to Safety" (STAMP/STPA). MIT Press, 2011. https://direct.mit.edu/books/book/2908/. Hazards as failures of the control structure rather than of components; law IV and the page's framing.
[Little 1961] John D. C. Little, "A Proof for the Queuing Formula L = λW". Operations Research 9(3), 1961. https://doi.org/10.1287/opre.9.3.383. Saturation and the bistable region near full utilisation; law II. (shared)
[Meadows 2008] Donella H. Meadows, "Thinking in Systems: A Primer". Chelsea Green, 2008. https://www.chelseagreen.com/product/thinking-in-systems/. Stocks, flows, feedback, and leverage points; law II and the page's framing.
[Meta 2021] Meta Engineering, "More details about the October 4 outage". engineering.fb.com, 2021. https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/. DNS withdrawing BGP routes on lost contact created a cyclic dependency that also severed the tools needed to recover; law I.
[Ongaro & Ousterhout 2014] Diego Ongaro & John Ousterhout, "In Search of an Understandable Consensus Algorithm" (Raft). USENIX ATC, 2014. https://raft.github.io/raft.pdf. A consensus group as a home for a cross-party invariant; law III.
[Perrow 1984] Charles Perrow, "Normal Accidents: Living with High-Risk Technologies". Basic Books, 1984. https://press.princeton.edu/books/paperback/9780691004129/normal-accidents. Tight coupling and interactive complexity as the source of system-level accidents; law I and the page's framing.
[Principles of Chaos 2015] "Principles of Chaos Engineering". 2015. https://principlesofchaos.org/. Rehearsing emergent failure on the real system, on purpose; law V. (shared)
[Reason 1990] James Reason, "Human Error" (the Swiss-cheese model). Cambridge University Press, 1990. https://doi.org/10.1017/CBO9781139062367. Common-mode failure as independent defences whose holes line up; law I.
[Shapiro et al. 2011] Marc Shapiro, Nuno Preguiça, Carlos Baquero & Marek Zawirski, "Conflict-free Replicated Data Types". SSS, 2011. https://doi.org/10.1007/978-3-642-24550-3_29. Convergent state that needs no coordinator; law III. (shared)
[Sigelman et al. 2010] Benjamin H. Sigelman et al., "Dapper, a Large-Scale Distributed Systems Tracing Infrastructure". Google, 2010. https://research.google/pubs/pub36356/. Tracing the path across services to localise whole-system latency; law V. (shared)
[Sterman 2000] John D. Sterman, "Business Dynamics: Systems Thinking and Modeling for a Complex World". Irwin/McGraw-Hill, 2000. https://www.mhprofessional.com/. Oscillation and instability from coupled feedback loops; laws II, IV.