Fallacies of Distributed Computing

The fallacies of distributed computing are eight false assumptions that developers implicitly make when building systems that communicate over a network. Peter Deutsch identified the first seven at Sun Microsystems in 1994, and James Gosling added the eighth. Despite being over 30 years old, these fallacies remain the most common source of distributed system failures because the cloud abstracts the network just enough to make developers forget it exists -- until it breaks.

The first fallacy -- the network is reliable -- is the most impactful. Every network call can fail: packets are dropped, connections time out, DNS fails to resolve, and entire availability zones go offline. In 2017, a single S3 outage in us-east-1 cascaded across hundreds of services because they assumed S3 was always reachable. The second fallacy -- latency is zero -- causes systems designed for local function calls to perform catastrophically when those calls cross a network. A loop that makes 100 sequential database calls takes microseconds locally but seconds over a network. The third fallacy -- bandwidth is infinite -- leads to chatty protocols that transfer entire objects when only a few fields are needed, collapsing under load when the network saturates.

The remaining fallacies are equally dangerous. The network is secure (fallacy 4) leads to unencrypted internal traffic that is exploitable after any perimeter breach. Topology doesn't change (fallacy 5) causes hard-coded IP addresses and brittle service configurations that break during deployments, failovers, or cloud instance replacements. There is one administrator (fallacy 6) ignores that modern systems span multiple teams, cloud providers, and even organizations, each with different policies, maintenance windows, and security requirements. Transport cost is zero (fallacy 7) ignores serialization overhead, TLS handshake costs, and cloud data-transfer charges that can dominate infrastructure budgets. The network is homogeneous (fallacy 8) assumes uniform network equipment and protocols, when real systems traverse WiFi, cellular, corporate firewalls, CDN edges, and submarine cables.

These fallacies remain critically relevant in 2026 because cloud computing creates a dangerous illusion of reliability. Managed services, auto-scaling, and multi-AZ deployments hide the network's complexity but do not eliminate it. A developer calling an AWS Lambda function from another Lambda function is still making a network call that can time out, be throttled, or hit a cold start. Understanding these fallacies is the first step toward building resilient systems that handle failure as a normal operating condition rather than an exceptional surprise.

Imagine you are passing notes to a colleague across the office. You assume: the note always arrives (reliable), it arrives instantly (zero latency), you can send as many notes as you want (infinite bandwidth), nobody reads it in transit (secure), your colleague is always at the same desk (topology stable), and only you control the note-passing system (one admin). Now imagine the office expands to 10 buildings across 3 cities. Notes get lost in transit, take hours to arrive, the mail room has capacity limits, anyone in the mail chain can read them, people move desks daily, and different buildings have different mail policies. Distributed computing is the 10-building version, but developers keep designing for the single-office case.