The 8 Fallacies of Distributed Computing

The list every distributed-systems engineer carries in their head

In 1994 (extended by James Gosling), Peter Deutsch named the false assumptions engineers keep making about networks. Decades later, essentially every distributed-systems outage still traces back to one of them. This isn't trivia — it's a design checklist: for any remote call, ask "which fallacy am I assuming?"

The 8 fallacies — reality and the design defense

Fallacy ("we assume…")	Reality	Design defense
1. The network is reliable	connections fail, packets drop, services are down	timeouts, retries with jitter + idempotency, circuit breakers
2. Latency is zero	a remote call is ~0.5ms (same DC) to ~150ms (cross-continent)	minimize round trips, batch, cache, colocate; never loop over remote calls
3. Bandwidth is infinite	links saturate; big payloads queue	compress, paginate, stream, trim payloads; watch fan-out
4. The network is secure	the wire is hostile; insiders too	TLS/mTLS, authn/authz, zero-trust, encrypt at rest
5. Topology doesn't change	nodes come and go; IPs change; autoscaling	service discovery, health checks, no hardcoded hosts
6. There is one administrator	many teams/orgs own pieces; versions drift	versioned, backward-compatible APIs; defensive parsing
7. Transport cost is zero	serialization burns CPU; egress bandwidth costs money	efficient formats (protobuf), batch, mind cloud egress $
8. The network is homogeneous	mixed hardware, protocols, library versions	standard protocols; don't assume peer capabilities

How to actually use it

Run it as a pre-mortem lens on any design with a network hop:

• "This call can fail or time out" (#1) → is it idempotent so a retry is safe? Cross-link: Retries, Idempotency keys.
• "This loops over N remote calls" (#2) → the latency stacks; batch it. The latency numbers are your intuition.
• "This node's address is hardcoded" (#5) → use discovery; tie to Heartbeat/health checks.
• "Two services both write this" (#6) → version the contract; never break the wire format.

Notice how the fallacies generate the rest of the systems curriculum: #1 → retries/circuit-breaker/idempotency, #2 → caching/CDN/estimation, #4 → TLS/mTLS, #5 → service discovery. They are the why behind the patterns.

Takeaways

• Every remote call quietly assumes an instant, reliable, free, secure, stable wire — all eight are false.
• Use the list as a design checklist / pre-mortem: for each network hop, which fallacy am I assuming, and what's my defense?
• The fallacies are the root cause behind retries, idempotency, caching, TLS, and service discovery — learn the why, not just the pattern.

---

Re-authored for this guide; mental-model diagram hand-authored as SVG. The list is Peter Deutsch & James Gosling's "Fallacies of Distributed Computing." See also: Capacity Estimation (latency numbers), Replication Lag & Failover, Rate Limiting, and the microservices resilience patterns (retry, circuit breaker, bulkhead).

I just read a lesson on **The 8 Fallacies of Distributed Computing** (System Design) and want to truly understand it. Explain The 8 Fallacies of Distributed Computing from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **The 8 Fallacies of Distributed Computing** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **The 8 Fallacies of Distributed Computing** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **The 8 Fallacies of Distributed Computing** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.