the fallacies of distributed computing
When programmers first build something that talks across a network, they tend to reason about it as if it were still one local program — and they quietly assume a list of comforting things that simply are not true. The fallacies of distributed computing are a famous list (often eight, associated with Peter Deutsch and colleagues at Sun) of exactly these false assumptions. They are collected not as trivia but as a checklist of the mistakes that keep biting newcomers, because each one, once believed, leads to a fragile system.
The classic eight are: (1) the network is reliable — but messages get lost; (2) latency is zero — but a remote call takes vastly longer than a local one; (3) bandwidth is infinite — but big data clogs the pipe; (4) the network is secure — but it can be eavesdropped and attacked; (5) topology does not change — but machines and routes come and go; (6) there is one administrator — but real systems span many owners and policies; (7) transport cost is zero — but serializing and moving data costs CPU and money; and (8) the network is homogeneous — but it mixes many devices, protocols, and speeds. Notice how each fallacy is just an unstated, optimistic default carried over from single-machine thinking.
Why it matters: this list is a practical antidote to over-trusting the network. A program that assumes calls never fail will crash the first time one does; one that assumes zero latency will feel painfully slow when chatty calls cross the wire; one that assumes a secure network will be breached. Treat the fallacies as design questions to answer up front — what happens when this call is lost, slow, or tampered with? — and you build the timeouts, retries, encryption, and capacity planning that distributed systems actually need. The honest summary: the network is not a faster, longer wire inside one machine; it is a hostile, unreliable medium, and pretending otherwise is how distributed systems fail.
A new app fetches a user's 50 friends by making 50 separate remote calls in a loop, assuming each is "instant". On a developer's laptop talking to a local server it feels fine; in production, each call crosses the network with real latency, and the page takes ten seconds to load. Fallacy 2 (latency is zero) bit them — the fix is to fetch all 50 in one call.
A checklist of comforting lies about the network. Believing any one of them builds a fragile system.
These are not obscure edge cases — they are the default mistakes. The mental fix is to stop treating a remote call like a local one: assume it can be lost, slow, insecure, and costly, and design for that from the start.