Fallacies of Distributed Computing

The network is not reliable, latency is not zero, and bandwidth is not infinite. Design as if you know it.

Each of the eight assumptions is false in the long run, so design for the network as it really behaves.

To an executive

Splitting a system into services replaces reliable internal calls with network calls that fail and slow down. Ignoring this leads to outages and unplanned work.

To an engineer

Design every remote call assuming the network can fail, add delay, run out of bandwidth, or change shape. Set timeouts, handle retries and don't treat it like a local function.

The idea

At Sun Microsystems in the 1990s, Peter Deutsch listed seven assumptions that designers of distributed systems tend to make and that prove wrong in the long run. James Gosling later added an eighth. Together they are known as the eight fallacies of distributed computing:

The network is reliable.
Latency is zero.
Bandwidth is infinite.
The network is secure.
Topology doesn't change.
There is one administrator.
Transport cost is zero.
The network is homogeneous.

Every decomposition into services turns function calls into network calls, and imports all eight fallacies into code that used to be safe.

Why it works

It names failures people forget. Local development hides the network. A short, memorable list brings it back into the design conversation.

Each fallacy implies a design response. Unreliable networks need timeouts and retries; non-zero latency needs fewer, coarser calls; insecure networks need encryption and authentication.

It is quick to apply. Eight questions fit into any design review and expose weak spots fast.

Where it applies

Microservice decompositions, where in-process calls become remote calls.
Monolith-to-services migrations, where existing code assumes calls are cheap and always succeed.
Hybrid and multi-cloud designs, where topology, administration and transport costs vary.
Mobile and edge clients, where networks are slow, expensive and intermittent.

How to apply

Walk the list in review. For each remote call, ask which fallacies the design assumes.
Give every call a failure mode. Set timeouts, retries with backoff, idempotency and a defined fallback.
Count and batch the calls. Reduce chatty, sequential calls, and run independent ones in parallel.
Secure and observe the links. Encrypt and authenticate traffic between services, and trace requests across hops.

Example scenario

A monolith was split into a dozen services. A product page that once made about 40 in-process calls now made 40 network calls, many of them one after another. Median latency rose from tens of milliseconds to over a second, and any slow service made the whole page time out.

A review against the fallacies led to three changes: a backend-for-frontend that fetched data in parallel, coarser APIs that returned what the page needed in one call, and timeouts with fallbacks for optional sections. Latency came back close to its old level, and a slow recommendations service now hid one panel instead of breaking the page.

Questions to ask

What exactly happens when this call times out — for the caller, the callee and the user?
How many network hops does one user request make, and are any of them sequential?
Which of the eight fallacies does this design quietly assume away?

When not to use it

Single-process systems, where calls really are local.
As a complete checklist; the list says nothing about clocks, ordering or partial failure inside a node, which also matter.

How it misleads you

Using the fallacies to reject distribution entirely. They are design constraints to address, not a veto. The other trap is ticking them off once: networks, topologies and administrators change, so the assumptions need revisiting as the system grows.