The Eight Fallacies of Distributed Computing
Why this matters: every distributed-systems outage you will ever debug traces back to someone assuming one of these eight things. They are not exotic edge cases — they are the default mental model of anyone who learned to program on one machine.
Key takeaway
The fallacies are the precise list of what the network abstraction hides. Learn them as a checklist: for each one, know the falsehood, the symptom when it bites, and the design force it creates. This is the spine the rest of the chapter hangs on.
The list
Catalogued at Sun Microsystems by L. Peter Deutsch and colleagues, these are assertions engineers assume are true and that are always false at scale.
| # | The fallacy | Reality | Design force it creates |
|---|---|---|---|
| 1 | The network is reliable | Packets drop; links flap; partitions happen | Timeouts, retries, idempotency, circuit breakers |
| 2 | Latency is zero | A cross-region round trip is ~150 ms — 1,000,000× a memory read | Batch calls, colocate data, cache, go async |
| 3 | Bandwidth is infinite | Links saturate; egress is metered and billed | Compression, pagination, binary encodings, CDNs |
| 4 | The network is secure | Anything on the wire is readable and forgeable | TLS everywhere, authn/authz per hop, zero trust |
| 5 | Topology doesn't change | Nodes are added, killed, rescheduled, and moved constantly | Service discovery, no hardcoded IPs, consistent hashing |
| 6 | There is one administrator | Many teams, many clouds, many change windows | Versioned APIs, backward compatibility, graceful degradation |
| 7 | Transport cost is zero | Serialization burns CPU; cross-AZ traffic costs money | Efficient codecs, locality-aware routing, chattiness budgets |
| 8 | The network is homogeneous | Mixed languages, protocols, versions, and hardware | IDLs and schemas, explicit contracts, protocol negotiation |
Why "latency is zero" deserves its own numbers
Fallacy 2 is the one that silently destroys designs, because the difference is not a factor of two — it is a factor of a million. Approximate, order-of-magnitude figures worth memorizing:
| Operation | Rough time | Scaled to human terms |
|---|---|---|
| L1 cache reference | ~1 ns | 1 second |
| Main memory reference | ~100 ns | ~2 minutes |
| SSD random read | ~100 us | ~1 day |
| Round trip in same datacenter | ~500 us | ~6 days |
| Disk seek (spinning) | ~10 ms | ~4 months |
| Round trip California to Netherlands | ~150 ms | ~5 years |
Read the right-hand column again. A function call that becomes a cross-region RPC is a one-second task that now takes five years.
Latency is not a number, it is a distribution
Fallacy 2 has a subtler form that separates senior answers from junior ones: engineers quote average latency, and users experience the tail.
If one call has a p99 of 100 ms, and a request must make 100 such calls, then the odds that none of them hits the slow path are 0.99^100, or about 37%. Roughly 63% of your requests hit at least one p99 event. The tail becomes the median.
This is tail latency amplification, and it is why large fan-out systems invest in hedged requests, tied requests, and aggressive per-call deadlines.
Fallacy 1 is the one with no workaround
"The network is reliable" is special because it cannot be engineered away — only handled. When a call does not return, you are in a state single-machine programming never prepared you for:
A local function call has two outcomes: it returned, or it threw. A remote call has three, and the third one — "I don't know" — has no equivalent on a single machine. Every retry policy, every idempotency key, and every consistency model in this chapter exists to cope with that third branch.
Key takeaway
The defining difficulty of distributed systems is partial failure: some parts of the system are working and some are not, and the working parts cannot reliably tell which is which. The fallacies are eight different ways of forgetting that.
Using the fallacies in an interview
They are a ready-made structure for pressure-testing any design — yours or someone else's. Walk an arrow on your diagram and ask:
- What happens if this call never returns? (1)
- How many round trips is this, and where are the two endpoints? (2, 7)
- How big is this payload, and how often? (3)
- Who is allowed to make this call, and is it encrypted? (4)
- How does the caller find the callee? (5)
- Who else deploys to this path, and what happens if they ship a new version first? (6, 8)
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | Knows calls can fail and adds a retry: "we'd retry if the service is down." |
| L5 | Distinguishes failure modes and bounds them: "timeout at 200 ms, retry twice with exponential backoff and jitter, then fail fast." |
| Staff+ | Reasons about the aggregate: "retries multiply load exactly when the system is unhealthy, so backoff plus jitter plus a circuit breaker plus a retry budget — otherwise we've built a self-DDoS." |
Next: the abstraction that hides all eight of these behind a function call.