Fallacies of Distributed Computing

In the 1990s, engineers at Sun Microsystems (L Peter Deutsch and others) wrote down the assumptions that newcomers to distributed systems make, and which eventually burn them. Thirty years on, the list hasn’t aged a day.

The eight fallacies

Fallacy	Reality	What to do about it
1. The network is reliable	Packets drop, connections reset, cables get cut	Timeouts, retries with backoff, idempotent operations (Message Delivery Semantics)
2. Latency is zero	Every hop costs milliseconds; a chatty design costs seconds	Batch calls, cache, avoid N+1 requests
3. Bandwidth is infinite	Payloads compete for limited pipes, especially on mobile	Paginate, compress, send diffs
4. The network is secure	Anything on the wire can be read or tampered with	TLS everywhere, authenticate every hop
5. Topology doesn’t change	Servers come and go; deploys move everything	Service discovery; clients that reconnect
6. There is one administrator	Many teams, vendors and policies share the path	Clear ownership, contracts, observability
7. Transport cost is zero	Serialisation, egress fees and infrastructure all cost	Measure it; choose formats deliberately
8. The network is homogeneous	Different hardware, protocols and versions everywhere	Standard protocols; tolerate old clients

Why they bite

Each fallacy is tempting because it’s nearly true in development. On your laptop, the “network” is localhost: fast, reliable, secure and unchanging. The bugs only appear in production, under load, at the worst moment. The fallacies are really a list of the ways failure sneaks in.

The frontend is a distributed system too

A browser talking to an API is two computers on an unreliable network. Real-time UIs make this vivid:

• A WebSocket will drop. Topology changes every time you deploy, so the client must reconnect with jitter and replay what it missed.
• A page that fires twenty requests on load is learning fallacy two the hard way.
• A mobile user in a tunnel is fallacy one and three.

In practice

I use the list as a design-review checklist: for each arrow on the diagram, which fallacy does it assume? It’s caught missing timeouts, unbounded retries and a “simple” polling design that would have hammered a backend. When something does go wrong anyway, Observability is how you find out which fallacy it was.