Fallacies of Distributed Computing
The Fallacies of Distributed Computing are a compact checklist of invalid assumptions commonly made when software interaction crosses network, process, administrative, or other independently governed boundaries. The catalog is associated with L. Peter Deutsch and other contributors at Sun Microsystems.
The fallacies are not a theorem, a complete failure model, or a claim that every remote interaction fails. They are prompts to replace silent optimism with explicit boundaries, assumptions, measurements, protocols, and recovery behavior.
Cohesive Correspondence
| Fallacious assumption | Cohesive correction |
|---|---|
| Network interaction is reliable | Failure models must admit loss, delay, partition, crash, corruption, overload, and correlated disruption as appropriate. Delivery, acknowledgment, retry, idempotency, and recovery claims remain scoped to specific boundaries. |
| Latency can be treated as zero | Service levels, queueing theory, and locality make response-time distributions, distance, serialization, queueing, and dependency fanout visible. A remote operation cannot safely inherit the cost model of a local call. |
| Bandwidth is effectively unlimited | Payload size, framing, fanout, replay, replication, repair, and control traffic consume finite network and processing capacity. Flow control, admission, batching, compression, retention, and capacity planning require declared units and bottlenecks. |
| The network is inherently secure | Every crossed boundary requires explicit trust, identity, authentication, authorization, confidentiality, integrity, and audit decisions. Semantic authority and transport reachability are not substitutes for those controls. |
| Topology remains fixed | Placement, membership, routes, leaders, partitions, replicas, and dependencies change through scaling, deployment, failover, migration, and repair. Infrastructure graphs, routing, compatibility, and recovery must represent coexistence and transition. |
| One administrator controls the system | Distributed systems cross teams, accounts, providers, regions, organizations, policies, credentials, and change cadences. Authority, policy scopes, interfaces, and compatibility boundaries must identify who can decide and change what. |
| Transport has no meaningful cost | Communication consumes latency, bandwidth, CPU, memory, serialization work, storage, energy, money, and operational attention. Locality, service levels, capacity planning, and realization evidence must account for the selected cost boundary. |
| The network and its participants are homogeneous | Protocol, schema, runtime, architecture, provider, capability, and version differences are normal. Interfaces, protocols, and compatibility and evolution must state negotiation, coexistence, and unsupported cases. |
Several rows expose areas that the current public graph does not yet give dedicated operational entries. In particular, security and administrative governance are only partially expressible through authority, policy, policy scopes, boundaries, and observability and provenance. This reference records the obligation without pretending those concepts form a complete security or governance model.
Location Transparency
Location transparency separates a logical name or interface from a participant's current physical placement. That indirection can support mobility, routing, replication, failover, and a stable programming surface. It does not make local and remote interaction operationally equivalent.
An abstraction becomes hazardous when uniform syntax conceals latency, partial failure, serialization, bandwidth, topology, security, administration, or transport cost from the model and from the policies responsible for handling them. A location-transparent actor address or service reference may hide coordinates from application code while the system graph still exposes placement, network, failure, authority, and recovery boundaries.
Location transparency is therefore a selective interface property, not a universal design goal. Some consumers need explicit locality constraints, co-location guarantees, region or zone selection, data-sovereignty boundaries, affinity, failure-domain separation, or a rule that an operation must not become remote. The useful discipline is to hide coordinates where they are irrelevant while preserving their operational consequences.
Jim Waldo, Geoff Wyant, Ann Wollrath, and Sam Kendall's A Note on Distributed Computing gives the stronger warning behind this distinction: distributed interactions differ intrinsically from single-address-space interactions because latency, memory access, concurrency, and partial failure cannot be abstracted away safely.
Modeling Checks
- Which network, process, runtime, storage, authority, or administrative boundaries does the interaction cross?
- Which failures, delays, partitions, topology changes, and compatibility differences are admitted?
- Which observations establish delivery, completion, latency, capacity, security, and cost claims?
- Which participant owns retry, timeout, failover, upgrade, credential, and recovery decisions?
- Does a uniform interface conceal a remote boundary whose failure or cost changes caller behavior?
- Which placement facts may remain hidden, and which operational consequences must remain explicit?
- Which fallacy is still being assumed rather than replaced by a modeled requirement and supporting evidence?
Formal relations
documents: Failure Models — Organizes recurring invalid reliability and failure assumptions that must be replaced by explicit fault, delay, recovery, and progress models.documents: Locality — Relates latency, transport cost, placement, and location transparency to boundary-relative access and interaction costs.documents: Compatibility and Evolution — Relates changing topology, administration, and heterogeneity to explicit coexistence, negotiation, and migration requirements.documents: Network — Qualifies network realization with finite reliability, latency, bandwidth, security, topology, administrative, cost, and heterogeneity assumptions.
External References
- Peter Jausovec, Fallacies of distributed systems, Oracle Developers, November 27, 2020.
- Software Engineering Radio, L. Peter Deutsch on the Fallacies of Distributed Computing, episode 470, July 27, 2021.
- Jim Waldo, Geoff Wyant, Ann Wollrath, and Sam Kendall, A Note on Distributed Computing, Sun Microsystems Laboratories Technical Report SMLI TR-94-29, 1994.