Fallacies of Distributed Computing

Core Idea

The Fallacies of Distributed Computing are eight false assumptions that architects commonly make when designing distributed systems, originally identified by Peter Deutsch and James Gosling at Sun Microsystems. These fallacies represent implicit assumptions that lead to architectural failures when systems move from single-process to distributed environments.

What Are the Fallacies of Distributed Computing?

Eight assumptions that work fine in monolithic applications but cause serious problems when network boundaries are introduced:

1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. The topology never changes
6. There is only one administrator
7. Transport cost is zero
8. The network is homogeneous

Each fallacy represents a dimension of distributed computing complexity that must be explicitly addressed in the architecture.

Historical context:

• First articulated in the 1990s at Sun Microsystems as engineers observed repeated failure patterns
• Peter Deutsch identified the first seven; James Gosling added the eighth about network homogeneity
• Despite being decades old, these fallacies remain highly relevant as microservices and cloud-native systems become the norm

Why This Matters

The fallacies explain why distributed systems are fundamentally harder than monolithic systems. You cannot decompose a working monolith into services without adding complexity to handle each distributed computing reality—every network call introduces failure modes, latency, security boundaries, and operational complexity that didn’t exist within a single process.

These fallacies are the reason architectural decisions involve trade-offs:

• Distributed architecture buys independent deployability, scalability, and fault isolation
• But requires explicitly handling network unreliability, latency budgets, inter-service security, and complex operational infrastructure
• The fallacies force architects to be honest about whether the benefits justify the costs

In practice, architects who understand these fallacies design systems with retry logic, circuit breakers, timeouts, distributed tracing, and service meshes to mitigate the risks. Those who ignore them build systems that work in development but fail in production.

Related Concepts

• Monolithic-vs-Distributed-Architectures — The fundamental architectural decision these fallacies inform
• Big-Ball-of-Mud-Anti-Pattern — What happens when distributed system complexity isn’t managed
• Client-Server-Architecture — The simplest distributed pattern that first exposes these fallacies
• Fallacy-The-Network-Is-Reliable — The most fundamental and impactful fallacy
• Fallacy-Latency-Is-Zero — The performance implications of distributed calls
• Architecture-Characteristics-Categories — How these fallacies affect operational characteristics
• Trade-Offs-and-Least-Worst-Architecture — These fallacies exemplify why all architectures involve trade-offs

Sources

• Richards, Mark and Neal Ford (2020). Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media. ISBN: 978-1-492-04345-4.

  • Chapter 9: Foundations
  • Discusses how these fallacies impact architectural style selection
  • Available: https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/

• Deutsch, Peter (1994-1997). “The Eight Fallacies of Distributed Computing.” Originally articulated at Sun Microsystems.

  • Original source identifying first seven fallacies
  • Widely documented in industry literature and technical articles
  • Historical context available through various technical publications

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.