The moment your software talks to another machine over a network, a set of comfortable assumptions you didn't know you were making become false. Engineers at Sun Microsystems catalogued eight of them decades ago, and every one still catches teams building their first distributed system today.
Key Takeaways
- The eight fallacies are false assumptions programmers make about networks, catalogued at Sun Microsystems (the eight fallacies).
- They include "the network is reliable," "latency is zero," and "bandwidth is infinite" (the fallacies).
- Systems built on these assumptions get needlessly complex and break in production (the eight fallacies).
- Distributed systems are a different discipline, and treating them like local code is the core mistake.
The Eight
Bill Joy and Dave Lyon named the first four; Peter Deutsch added three more; James Gosling added the eighth in 1997 (the eight fallacies). Each is an assumption that's safely true inside one machine and dangerously false across a network:
1. The network is reliable. It isn't. Packets drop, connections die mid-request.
2. Latency is zero. A local call is nanoseconds; a network call is milliseconds, a million times slower.
3. Bandwidth is infinite. It's finite and shared, and big payloads clog it.
4. The network is secure. Anything on the wire can be read or tampered with unless you protect it.
5. Topology doesn't change. Servers move, scale, and disappear constantly.
6. There is one administrator. In reality, many parties control different pieces.
7. Transport cost is zero. Serializing, sending, and moving data costs real time and money.
8. The network is homogeneous. Different systems, protocols, and versions must interoperate.
The common thread: each assumption is invisible until it fails, and it fails in production, under load, at the worst time (the fallacies).
Why They Matter So Much Now
These fallacies used to be a specialist's concern. Now nearly every startup app is distributed by default: it calls a payments API, a search service, a queue, three SaaS tools, and its own microservices. Every one of those calls crosses a network and inherits all eight fallacies. A junior developer writes "charge this card" as a plain function call, as if it were local; a senior knows that call can hang, fail halfway, get retried, arrive twice, or return after the client gave up, and codes for all of it.
That gap connects straight to idempotency (because retries happen), observability (because you can't see across the network without it), and the whole reason distributed systems earn a reputation for being hard.
A Concrete Version
A team ships a feature that calls an external API in the request path, assuming it's fast and reliable, latency-is-zero and network-is-reliable in one move. It works in testing. In production, the third party has a slow afternoon, the calls pile up, each request holds a connection waiting, the connection pool exhausts, and the entire app goes down, taking far more than the one feature with it. The bug lived in the assumption that a network call behaves like a local one. A timeout, a circuit breaker, and an async path would have contained it.
The Honest Counterpoint
Aware of the fallacies, teams can overcorrect into paranoid complexity, wrapping every call in retries, circuit breakers, queues, and caches until the system is a distributed-systems showpiece that a monolith would have outperformed. The fallacies are a warning to respect the network, not a mandate to defend against every failure everywhere. The best defense is often to distribute less: fewer network hops, a monolith over premature microservices, and reserving the heavy machinery for the calls that genuinely need it. Respect the network; don't build a cathedral to it.
What This Means for Teams
The fallacies are a compact test of whether someone has actually operated distributed systems or only read about them. An engineer who instinctively asks "what happens when this call times out, or runs twice?" has been burned before, and that scar tissue is worth a lot when your product depends on a dozen network calls per request. It's a specific, testable form of the judgment we screen for in how to verify a senior engineer. See available engineers.
Frequently Asked Questions
What are the fallacies of distributed computing?
Eight false assumptions programmers make about networks, catalogued at Sun Microsystems: 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, and the network is homogeneous.
Why do they still matter?
Because nearly every modern app is distributed by default, calling APIs, queues, and services over networks. Each call inherits all eight fallacies, and systems built as if they were false break in production.
What's the most common one to get burned by?
"The network is reliable" and "latency is zero." Teams put a network call in the request path assuming it's fast and dependable, and a slow or failing dependency takes the whole app down.
How do I guard against them without over-engineering?
Respect the network with timeouts, retries with idempotency, and circuit breakers on the calls that need them, but distribute less overall. Fewer network hops beats heavy resilience machinery around every call.
The Bottom Line
The instant your code crosses a network, eight comfortable assumptions turn false, and the systems that ignore them break in production under load. Treat distributed systems as their own discipline: assume calls can fail, hang, or duplicate, code defensively where it matters, and reduce the number of network hops you take. Respect the network without building a monument to it.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
