Fallacies of Distributed Computing

Table of Contents

🟠 P1 — Peter Deutsch’s eight fallacies; useful as a shortcut reference in interviews

Problem #

Engineers new to distributed systems implicitly assume properties that don’t hold. These assumptions lead to brittle systems that fail in production under real-world conditions.

The Eight Fallacies #

	Fallacy	Reality	Design Implication
1	The network is reliable	Packets get dropped, connections reset	Retry, idempotency, circuit breakers
2	Latency is zero	Network calls are 1000x slower than local calls	Batch calls, caching, async where possible
3	Bandwidth is infinite	Serialisation format and payload size matter	Protobuf > JSON for high-throughput
4	The network is secure	Every hop is an attack surface	mTLS, auth at service boundaries
5	Topology doesn’t change	Services move, IPs change, regions shift	Service discovery, DNS, load balancers
6	There is one administrator	Multiple teams, orgs, cloud providers	Blast radius, ownership boundaries
7	Transport cost is zero	Cloud egress fees, serialisation CPU cost	Minimise cross-region traffic, compress
8	The network is homogeneous	Different hardware, OS, languages, versions	Well-defined APIs, schema evolution

Instinct #

These are useful as a checklist during design review. When sketching a system, mentally walk through each fallacy: “Am I assuming the network is reliable here? What happens when it isn’t?”

In interviews, invoking specific fallacies by number is a communication bandwidth shortcut — see also: Back-of-Envelope Estimation for the numbers that back up fallacy #2 and #3.

Reference #

Fallacies of Distributed Computing, Explained (also, wikipage)— Arnon Rotem-Gal-Oz