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

Put numbers on #3 and #7 — the two everyone hand-waves: a 1 MB JSON payload at 10K QPS is 10 GB/s ≈ 80 Gbps, saturating a 25 Gbps NIC more than 3× over — no amount of retrying fixes a full pipe. Protobuf typically cuts the payload 2–10×; and at cloud egress rates of ~$0.05–0.09/GB, that same stream sent cross-region is ~$40K+/day (10 GB/s × 86,400s ≈ 864 TB/day). Bandwidth and transport cost are capacity and budget line items, not abstractions.

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.

Pre-mortem in practice: payment webhook receiver

Suppose you are building a service that receives payment webhooks from a provider like Stripe and updates the order status. Here is how running the fallacy checklist changes the design.

Fallacy assumed	Naive design	Design after checklist
#1 Network is reliable	Process webhook synchronously; if it fails, the payment is "lost."	Return 200 immediately, then process asynchronously with retries, idempotency keys, and a dead-letter queue.
#2 Latency is zero	Call the order service and inventory service while the provider waits for an HTTP 200.	Accept the webhook, ack it, and fan out to downstream consumers with a timeout budget; never block the provider's HTTP response on internal work.
#5 Topology doesn't change	Hardcode the order-service IP.	Use service discovery + health checks; the webhook receiver routes to healthy instances.
#6 One administrator	Assume the webhook payload format never changes.	Version the event schema and parse defensively; unknown fields are ignored, not rejected.

Before: a synchronous, hardcoded, best-effort processor. After: an async, idempotent, discovered, defensively-parsed pipeline. The checklist didn't add complexity for its own sake — each change is a direct answer to a false assumption (Release It!, Nygard; Deutsch/Gosling fallacies).

Post-mortem in practice: the retry storm

The webhook pre-mortem runs the checklist forward; the fallacies' strongest teaching mode is running it backward over a real outage. The classic cascade, step by step, each step naming the fallacy it violates:

1. A 30-second network blip drops every in-flight connection to a service (#1 — the network was assumed reliable, so nobody designed the retry policy for a correlated failure).
2. Every client times out at the same instant and retries in sync, without jitter — the moment the network heals, ~3× normal load arrives as one synchronized wave (#1 again: retry was the defense, but un-jittered retry is a weapon pointed at yourself).
3. The recovering service comes back cold-cached: every request misses the cache and falls through to the database, so each response is far slower than the steady-state numbers the capacity plan assumed (#2 — latency is not zero, and it is least zero right after a restart).
4. Slow responses hold connections and threads longer; 3× load meets degraded capacity; the service tips over again — and the outage is now self-sustaining, minutes after the original 30-second blip ended.

The fix set — each one a defense the table already named: jittered exponential backoff (desynchronizes the retry waves), idempotency keys (makes the retries safe to send at all), and a circuit breaker (stops hammering the recovering service and buys it time to warm its cache). If you can map an incident narrative onto fallacy numbers unprompted, you have internalized the list.

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).

The production control for each fallacy

All eight assumptions are always false — the question is never whether to defend, only which control and what you'll see if you skipped it.

• #1 Reliable — control: timeouts + budgeted, jittered retries + idempotency. Symptom skipped: a 30s blip becomes a multi-hour retry-storm outage.
• #2 Latency zero — control: batch round trips, colocate chatty services. Symptom: an API that was fine in one AZ death-spirals when a dependency moves cross-AZ.
• #3 Bandwidth infinite — control: pagination + a compression/payload budget. Symptom: p99 spikes correlated with payload-size deploys.
• #4 Secure — control: TLS/mTLS + authn/authz on every internal hop. Symptom: the breach post-mortem finds plaintext service-to-service traffic.
• #5 Topology stable — control: service discovery + health checks + connection pools that refresh. Symptom: errors pinned to one stale IP after an autoscale or deploy.
• #6 One administrator — control: versioned, backward-compatible schemas + defensive parsing. Symptom: another team's deploy breaks your parser at 2am.
• #7 Transport free — control: protobuf + batching + same-AZ placement. Symptom: the cloud-egress line item nobody can explain.
• #8 Homogeneous — control: version negotiation + capability discovery. Symptom: one canary client on an old TLS/protocol version breaks after a cipher deprecation.

Interviewer follow-ups & drills

1. Which fallacy hurts mobile clients most? Latency/bandwidth not infinite; network not reliable.
2. Drill: pick 3 fallacies and name one production control for each.

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.