The Fallacies of Distributed Systems: Understanding Common Network Assumptions

In 1994, Sun Microsystems researcher Peter Deutsch identified several common misconceptions about distributed systems, now known as the “Fallacies of Distributed Systems.”

The network is reliable

In reality, any communication can fail, so systems must provide mechanisms to detect and handle failures. An RPC call may return success, failure, or an unknown state (e.g., timeout). The server might be processing, succeeded, or failed, requiring the client to query, retry, or employ distributed transactions and compensating actions.

Latency is zero

Latency exists in every communication and heavily impacts user experience and performance. To mitigate it, avoid excessive network calls, use connection pooling, batch requests, cache results, employ CDNs, deploy across multiple regions, and consider publish/subscribe patterns to push updates.

Bandwidth is infinite

Bandwidth is limited; emerging scenarios such as autonomous vehicles can generate tens of terabytes of data per day, demanding careful bandwidth planning in application design.

The network is secure

Assuming trust in the network or its operators is a critical mistake. Modern security practices, including vulnerability assessments, security‑first design, and continuous monitoring, are essential to protect distributed systems.

All network communication is the same

Different protocols and transport mechanisms have distinct characteristics; developers must consider these differences when building applications.

These fallacies, originally articulated by L. Peter Deutsch and colleagues, serve as a reminder that robust distributed system design must account for unreliable networks, non‑zero latency, finite bandwidth, security risks, and protocol diversity.

architecturenotes.co/fallacies-of-distributed-systems/