Fallacies of Distributed Computing
The Fallacies of Distributed Computing are a set of incorrect assumptions that developers often make when designing distributed systems. They were originally articulated at Sun Microsystems in the 1990s and consisted of seven fallacies. Around 1998, an eighth fallacy was added to the list. These assumptions highlight common misconceptions about network behavior and the challenges inherent in distributed environments.
A fallacy is a mistaken belief, assumption, or pattern of reasoning.
Fallacy 1: The Network Is Reliable
Google has historically reinforced some of its submarine fiber-optic cables with protective materials such as Kevlar and steel. One reason for this additional protection is to reduce the risk of physical damage from external factors, including fishing equipment, anchors, and marine life. While shark bites on undersea cables have been documented, they are relatively rare compared to other causes of cable damage. This example illustrates how many factors can affect network reliability in distributed systems. Network failures are not limited to routers, switches, or communication links. Infrastructure components can fail, third-party services may become unavailable, cloud providers can experience outages, and power disruptions can take entire systems offline.
As a result, architects and developers should not assume that the network is always reliable. Distributed systems must be designed to handle partial failures, timeouts, retries, degraded service modes, and temporary loss of connectivity. The reality is that network reliability is influenced by numerous dependencies, many of which are outside the direct control of the application itself.
Common mitigation strategies include timeouts, retries with exponential backoff, circuit breakers, and bulkheads.
Fallacy 2: Latency Is Zero
Imagine a geo-distributed system that replicates data across multiple servers. When a balance update is performed, the change requires time to propagate to all redundant servers. This delay is not necessarily caused by network bandwidth limitations; it is a consequence of physical constraints. Even when data is transmitted over high-speed fiber-optic networks, information still needs time to travel between geographically separated locations and be processed by each replica.
Amdahl’s Law: “The overall improvement of a system is limited by the portion that cannot be improved.” Even data traveling through fiber-optic cables between China and the United States takes roughly 60–100 milliseconds one way, illustrating that some physical limits cannot be optimized away.
Fallacy 3: Bandwidth Is Infinite
Poorly designed software can introduce significant performance and scalability issues. Consider a service that needs to retrieve a single user’s email address. Instead of querying only the required record, the database request loads the entire table into memory and then filters the result set locally to extract the email.
In this case, the inefficiency is not caused by the size of the email itself, which is only a few dozen bytes, but by the unnecessary transfer of a much larger dataset — potentially on the order of gigabytes. This design effectively turns a simple lookup operation into a heavy network and memory load, creating avoidable latency and resource consumption.
Fallacy 4: The Network Is Secure
Running a service within an internal network does not eliminate the risk of external compromise. A low-privilege service or server within an organization can still be exploited, for example through vulnerabilities in its application layer or dependencies. Once compromised, it may be able to initiate internal network requests that were originally intended to be trusted.
Attackers can leverage this access to move laterally within the environment and interact with internal services that are not directly exposed to the internet. In the worst case, this can lead to unauthorized access to sensitive systems, including databases, if internal trust boundaries are not properly enforced.
Modern architectures often adopt Zero Trust principles and mutual TLS (mTLS) between services rather than assuming that internal network traffic is trustworthy.
Fallacy 5: Topology Doesn’t Change
Microservices are widely used today, primarily because they enable independent scaling of individual components. A service may initially run on two instances, and under increased load, a third instance can be automatically provisioned through autoscaling mechanisms. When traffic decreases, that additional instance can be terminated to optimize resource usage.
Get Uğur Cem Uçar’s stories in your inbox
Join Medium for free to get updates from this writer.
However, assuming that a third instance is always available can lead to unexpected behavior. Autoscaling is dynamic, and instances may be added or removed based on current demand and infrastructure constraints. If a system is designed with the implicit assumption of a fixed number of running instances, it can result in inconsistencies, race conditions, or failures when the actual runtime topology changes. Topology changes are not limited to scaling events. Services may be redeployed, migrated to different hosts, assigned new IP addresses, moved to another availability zone, or replaced entirely during maintenance and upgrades. This is one reason why service discovery and load balancing mechanisms are fundamental components of modern distributed systems.
Fallacy 6: There Is One Administrator
As organizations expand over time, their systems expand with them. New teams are formed, each with different responsibilities, technical approaches, and levels of authority. In such environments, multiple administrators typically operate across different parts of the system. Even the infrastructure itself may be managed by a cloud provider, introducing another administrative domain outside the organization’s direct control.
Even when the software itself is designed to be consistent, organizational structures are not centralized. This distribution of ownership and responsibility introduces variation in decision-making and configuration. As a result, these human and organizational inconsistencies can directly influence system behavior and lead to unexpected outcomes.
Conway’s Law: “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”
Fallacy 7: Transport Cost Is Zero
Consider an e-commerce application implemented as a monolith. As traffic grows, you may discover that the payment component requires additional CPU and memory resources to maintain acceptable performance. Since the entire application is deployed as a single unit, scaling often means allocating more resources to the whole system, even if only one part of it is under heavy load.
A common solution is to decompose the application into microservices. This allows individual services, such as the payment service, to be scaled independently, potentially reducing overall resource consumption. However, this architectural change introduces new costs and complexities. Additional infrastructure may be required, including load balancers, service discovery mechanisms, deployment pipelines, monitoring systems, and dedicated servers or containers.
Furthermore, communication that previously occurred through in-process function calls now takes place over the network using protocols such as HTTP or gRPC. These remote calls introduce latency, consume network bandwidth, and create additional failure scenarios that must be handled. As a result, while microservices can improve scalability and organizational flexibility, they also increase operational complexity and infrastructure costs. This trade-off is one of the key considerations when choosing between monolithic and distributed architectures.
Data gravity is a concept that indicates the more data you have in one place, the harder and more expensive it becomes to move that data, and the more other systems are pulled toward it. It is a practical manifestation of non-zero transport costs.
Fallacy 8: The Network is Homogeneous
Not every component in a distributed system behaves identically when processing the same event. Differences in operating systems, hardware, network configurations, software versions, and runtime environments can all influence behavior.
For example, Windows and Linux use different path conventions: Windows typically uses backslashes (\) while Linux uses forward slashes (/). As a result, commands and scripts that work correctly on one platform may require modification to run on the other. Similar differences can exist in physical infrastructure, network settings, system configurations, and even among application instances running the same code. Having different network vendors, cloud providers, middleware platforms, or even serialization formats can lead to heterogeneity within a distributed system. These differences may introduce compatibility issues, inconsistent behavior, and operational challenges, illustrating why it is unsafe to assume that the network is homogeneous.
Assuming that every node in a distributed system is homogeneous can lead to subtle bugs, deployment issues, and operational failures. Robust distributed systems are designed with the expectation that components may differ in meaningful ways.
Postel’s law: “Be conservative in what you send, liberal in what you accept.” Postel’s Law emerged as a practical guideline for interoperability in heterogeneous networks, where different systems may interpret specifications slightly differently.
The Fallacies of Distributed Computing remind us that distributed systems operate under real-world constraints. Networks fail, latency exists, bandwidth is limited, environments change, and complexity grows as systems scale. Understanding these assumptions helps engineers design systems that are more reliable, resilient, and better prepared for the realities of distributed computing.
