Common Distributed Computing Fallacies

Common Distributed Computing Fallacies

Introduction to Distributed Systems

• Fallacies of distributed computing can trip up developers and architects, acting like hidden pitfalls.
• Definition of distributed systems: components on different machines collaborate to appear as a single system.
• Interact/Communicate with other services over clearly defined interfaces.
• Referenced Leslie Lamport’s quote emphasizing that failures in parts of the system you’re unaware of can make your own computer unusable.
• The eight fallacies were devised by people at Sun Microsystems to guide newcomers in distributed software design.
• In today’s cloud-driven environment, almost every application is a distributed system—even outside of microservices.

Four Key Fallacies Explained

• The network is reliable: Networks still fail, despite improvements. All distributed and non-monolithic systems rely on networks, making this a core risk, especially in microservices with inter-service communication.
• Latency is zero: Data takes measurable time to travel across networks, limited by physics. Inter-process and in-process communication is much faster than networked interaction. Distributed architectures need to measure and plan for this latency, particularly when chaining multiple services where cumulative latency may impact end-user experience.
• Bandwidth is infinite: Networks have capacity constraints. High call volumes and large data payloads can quickly consume available bandwidth, potentially overwhelming systems and causing bottlenecks.
• The network is secure: Networks, including private ones, have larger potential attack surfaces than single-process applications. Security measures add additional latency, compounding earlier fallacies.

Practical Implications for Developers and Architects

• These fallacies are not just theoretical; they impact nearly all modern distributed, cloud and microservices-based applications.
• Not accounting for these fallacies will result in less robust or resilient systems.
• Developers should always design systems with these limitations and risks in mind, rather than making optimistic assumptions.

Suggested Action Items

• Assess current architecture for assumptions about network reliability, latency, bandwidth, and security.
• Monitor and measure network performance and bottlenecks in distributed deployments.
• Implement proactive error handling, security best practices, and latency budgeting in distributed system design.