Nygard's verdict: **integration points are the number-one killer of systems.** Every feed, every socket, process, pipe, or remote procedure call — even database calls — *can and will* hang, in ways obvious and subtle. Every connection into a system can hang it, crash it, or generate impulses at the worst possible time. A "standalone system that doesn't integrate with anything is rare, and almost useless," so the goal isn't to avoid integration points but to make them *safe*. The first mindset shift: a new architect focuses on the boxes in a diagram; an experienced one is more interested in the **arrows** — each arrow is an abstraction for a network connection, itself an abstraction over packets, and any layer can fail. Every integration point will eventually fail in some way, and the failure won't arrive as a tidy error through the protocol — expect protocol violations, slow responses, or outright hangs. The defenses introduced later are **Circuit Breaker, Timeouts, Decoupling Middleware, and Handshaking**; the testing defense is a **Test Harness** that can simulate each failure mode under load. ## Related - [[Second-Order Variety Problem in Distributed Systems]] — the systems-theory version of "arrows not boxes": failure emerges in the interaction space between components - [[Financial Contagion Travels Along Counterparty Exposure]] — the same connection-borne failure in finance: the map of who owes whom is the map of how failure spreads - [[Failure Modes Mirror Above and Below the Line]] — integration-point failures cascade across the technical and human layers alike - [[Weak Signals as Pre-Failure Indicators]] — why integration failures are hard to catch: slow responses and hangs, not tidy errors, are the weak signals before the loud failure --- *Source: [[Release It Second Edition]] (Michael T. Nygard, Pragmatic Bookshelf 2018) — Ch 4 — Stability Antipatterns*