Eight fallacies (Deutsch / Gosling): the network is reliable, latency is zero, bandwidth is infinite, the network is secure, topology doesn’t change, there is one administrator, transport cost is zero, the network is homogeneous. Each is “obviously false” — and each is routinely baked into designs implicitly.
The list is folklore from Sun Microsystems in the 1990s: it is attributed to L. Peter Deutsch and colleagues there, with the eighth added later by James Gosling. It was never a paper with data; it is a summary of how distributed designs kept failing. The empirical record came later. Bailis and Kingsbury, “The Network is Reliable” (ACM Queue, 2014), collected public postmortems and studies of real partitions — switch failures, misconfigured firewalls, GC pauses that looked like partitions to peers — in systems whose designers had assumed the network away.
How they appear in backend code. Reliable network: an HTTP client with no timeout, so one slow dependency exhausts the caller’s threads. Zero latency: an ORM loop issuing one query per row, fine on a laptop and 400 round trips across zones in production. Infinite bandwidth: a service returning a full object graph when the caller needs two fields. Secure network: plaintext between services “because it is internal” (32). Topology doesn’t change: IPs cached past a pod reschedule. Zero transport cost: cross-region replication priced only after the bill (78).
A checkable form. Every service-to-service call in the code must answer three questions: timeout? retry policy (24), and is the operation safe to retry (22)? what happens when the other side is unavailable? No answer = fallacy #1 baked in. The opposite error is treating an in-process call as remote “to be safe” — that is accidental complexity (40). Not expressible in code; expressed as a review checklist for every network boundary.