The fallacies of distributed computing

A list written at Sun Microsystems in the 1990s, and it still describes almost every distributed-systems bug written today — not because engineers haven't learned it, but because code that assumes these things is easier to write, and the assumptions only break under conditions that are easy to forget about until they happen.

Beginner

3 min read

Why this list exists

In the 1990s, engineers at Sun Microsystems noticed the same category of mistake showing up repeatedly in networked software: code written as though it were talking to something local and reliable, when it was actually talking across a network that is neither. They wrote down eight assumptions that new (and experienced) distributed-systems engineers habitually make — the fallacies of distributed computing — every one of them false, and every one of them still tempting to assume today.

The eight fallacies

The network is reliable. It isn't — packets get dropped, connections get reset, and any code that doesn't handle a failed request has quietly assumed this fallacy.
Latency is zero. A call to a service on the same machine and a call to a service across the world look identical in code, but one takes microseconds and the other can take hundreds of milliseconds — treating them the same is how a system ends up doing ten sequential network calls where one would do.
Bandwidth is infinite. Sending a large payload "just because it's convenient" works fine in local testing and falls over at real scale, when the network itself becomes the bottleneck.
The network is secure. Anything crossing a network can be intercepted or tampered with unless explicitly protected — this fallacy is exactly why Web Security's TLS and authentication content exists.
Topology doesn't change. Servers get added, removed, and rescheduled constantly in a modern cloud environment — code that hardcodes an assumption about which machine handles what breaks the moment infrastructure changes.
There is one administrator. Real systems span teams, vendors, and organizations, each changing their part independently — nobody has full visibility or control over the whole thing at once.
Transport cost is zero. Serializing, sending, and deserializing data costs real CPU time and real money (network egress, compute) — it is never free, even when it's fast.
The network is homogeneous. Different network paths have wildly different reliability and performance characteristics — a request between two servers in the same data center and one crossing continents are not interchangeable assumptions.

Why "just don't make these assumptions" isn't enough

Knowing the list doesn't automatically prevent the mistake, because code that assumes a reliable, instant, free network is genuinely simpler to write and read than code that defends against every possible failure. The practical skill this whole domain builds toward is knowing which assumptions are safe to make in a given context (a single data center's internal network fails far less often than a cross-region call) and designing deliberately for the ones that aren't — not eliminating every assumption uniformly, which would make simple systems needlessly defensive.

Where the rest of this domain pushes back on each fallacy

This list is really a preview of the whole domain: logical clocks (lessons 2–3) exist because you can't assume a shared, instant sense of time; replication and consensus (lessons 4–8) exist because you can't assume one machine is always reachable; failure detection (lesson 9) exists because you can't assume you'll be told when something breaks; and distributed transactions (lessons 10–11) exist because you can't assume an operation spanning multiple machines succeeds or fails as one atomic unit the way a single-machine transaction does.

The fallacies of distributed computing

Beginner

3 min read

Why this list exists

The eight fallacies

The network is reliable. It isn't — packets get dropped, connections get reset, and any code that doesn't handle a failed request has quietly assumed this fallacy.
Latency is zero. A call to a service on the same machine and a call to a service across the world look identical in code, but one takes microseconds and the other can take hundreds of milliseconds — treating them the same is how a system ends up doing ten sequential network calls where one would do.
Bandwidth is infinite. Sending a large payload "just because it's convenient" works fine in local testing and falls over at real scale, when the network itself becomes the bottleneck.
The network is secure. Anything crossing a network can be intercepted or tampered with unless explicitly protected — this fallacy is exactly why Web Security's TLS and authentication content exists.
Topology doesn't change. Servers get added, removed, and rescheduled constantly in a modern cloud environment — code that hardcodes an assumption about which machine handles what breaks the moment infrastructure changes.
There is one administrator. Real systems span teams, vendors, and organizations, each changing their part independently — nobody has full visibility or control over the whole thing at once.
Transport cost is zero. Serializing, sending, and deserializing data costs real CPU time and real money (network egress, compute) — it is never free, even when it's fast.
The network is homogeneous. Different network paths have wildly different reliability and performance characteristics — a request between two servers in the same data center and one crossing continents are not interchangeable assumptions.

The fallacies of distributed computing

Why this list exists

The eight fallacies

Why "just don't make these assumptions" isn't enough

Where the rest of this domain pushes back on each fallacy

Further reading

The fallacies of distributed computing

Why this list exists

The eight fallacies

Why "just don't make these assumptions" isn't enough

Where the rest of this domain pushes back on each fallacy

Further reading