21 years and counting of 'eight fallacies of distributed computing' (2025)

A deep dive into the eight fallacies of distributed computing, originally coined at Sun Microsystems, and why they still plague modern software development.

You’d think that by now, networks were well enough understood that people would stop making assumptions that we have known, almost since the dawn of networking, to be untrue. Yet as users, developers, and network administrators, we still seem curiously unable to let go of long-held beliefs.

Perhaps the best-known collection of mistaken ideas about networks is the eight fallacies of distributed computing.

The eight fallacies

The network is reliable
Latency is zero
Bandwidth is infinite
The network is secure
Topology doesn’t change
There is one administrator
Transport cost is zero
The network is homogeneous

Where did this list come from?

The list began with four original fallacies (the first four in the list), collected by Bill Joy and Tom Lyon, two of the original eight founders and employees of Sun Microsystems.

Sun integrated high-speed graphics, the UNIX operating system, and a working Internet protocol stack, which led to the explosion in desktop computing, their meteoric rise, and ultimate acquisition by Oracle Computing. When you use a Berkeley Software Distribution (BSD) variant, a Linux distribution, or even Android, you’re using technology that has followed a lineage from Sun Microsystems. Think of the ZFS file system, the Network File System (NFS) protocol for network file storage, and Java, to name a few.

The list was later expanded by L. Peter Deutsch, who added a further three fallacies while at Sun. The final fallacy was coined by James Gosling, who, fittingly, also worked at Sun, bringing us to the eight fallacies we now know and love.

Over time, these ideas have settled and inspired other lists of fallacies — for example, the fallacies surrounding dates and times, or the falsehoods people believe about names. I would be surprised if there weren’t more. We encounter these date and name errors constantly, whether filling in forms or interacting with assets on the web or in apps.

The underlying eight fallacies of distributed computing are buried ‘constants’ in our use of the network. They are worth thinking about as network operators, whether in protocol and software design, or how they impact users in daily life. By keeping them in mind, we can better address the behaviours that arise from these fallacies as we encounter them online.

The list is aimed at people writing network software: Applications that call into the network, services that are called from the network, and network protocols. It provides practical guidance — even if presented abstractly — on how to think about sending data through a network, and the questions you should ask. Questions such as:

Was it actually sent?
Was it received?
How can you tell?
Can you send it again, or is the data gone?
Does it even need to be sent again?
Do you have time to handle this data? How will it affect the rest of your program?
Does the network behave in ways you really understand, despite its complexity??

Looking at the fallacies case by case

What follows is my personal understanding of the meaning of each of the eight fallacies of distributed computing, as they relate to how the network behaves towards me and my services. Others have different views, and I may have gotten some things wrong.

1. The network is reliable

Measured as a whole, the Internet is probably broken somewhere, for some users, at all times. That we individually experience it as reliably available is a triumph of hope over experience. Claims of ‘five nines’ reliability often lead us to act as if ‘it won’t happen to me’.

More specifically, people tend to assume that once a packet is sent, it will be received. Most of the time, it is. But we still have to design protocols to handle the cases when it isn’t.

Consider the first of the three classic measures of a network’s behaviour: loss, delay, and jitter. ‘Loss’ is simply another way of saying ‘unreliable’. If your protocol doesn’t account for the fact that data can be lost, it will run into problems. Much of the Transport Control Protocol (TCP) and QUIC layers are specifically designed to recognise packet loss and handle it.

Internet Protocol (IP) — whether version four or six — does not guarantee delivery. That responsibility falls to higher layers if they are capable.

2. Latency is zero

Latency encompasses the other two network issues mentioned above: Delay and jitter. Delay is sometimes simply a function of distance, given the speed of light — but even this can be misunderstood, since the speed of light in fibre is slower than in a vacuum.

Additional delays occur when converting a signal from copper to fibre and sending it along a fibre optic link. Because of this, sending data via microwave, radio, or even laser between satellites can sometimes be faster than sending it through fibre.

Jitter, the variability of delay, is a major challenge for gaming and streaming protocols. Latency and loss are the reasons why services like Netflix both buffer data and use error-correcting codes. These techniques compensate for fluctuations in delay, providing a smooth and reliable playback experience.

3. Bandwidth is infinite

It’s tempting to think that in the modern Internet, we can sometimes treat bandwidth as effectively infinite for most practical purposes. The reality, however, is that many links in the system have more people sending packets than there are spaces available to carry them.

Dealing with the consequences of ‘less-than-infinite’ bandwidth introduces queuing, which in turn creates delay. With delay comes jitter, and under extreme conditions, packet loss. The limitations of finite bandwidth directly affect every network flow subject to these constraints.

In today’s network, where data is often ‘close by’ in a Content Delivery Network (CDN), we rarely notice this. In bandwidth terms, the limits of the network are often far removed from us — with one exception: our local home link.

We may use gigabit-capable devices, but our local link speed is often only a few hundred megabits. Can we exceed our home router’s capacity? Almost trivially. Can we exceed our home Wi-Fi network? Certainly. A modern mobile phone can sustain 400 Mbit/sec or more, but a Wi-Fi network purchased five years ago might cap out at 100 Mbit/sec.

Investing in network bandwidth to match expectations is like building roads to handle peak-hour traffic: you can make it appear that congestion doesn’t exist, but the cost may be higher than desired. When upgrading a home router to match the speed of new edge fibre delivery, we face the same question: how much bandwidth do we really need?

4. The network is secure

In the days of monopoly telecommunications, when a single provider ran networks across an entire economy, there was one major risk: that the provider might fail to ensure the privacy of our data. Typically, they controlled all the infrastructure, and intrusions were rare, if not unheard of. Encoding overhead was minimal, and law enforcement could access data through a single channel.

Today, networks run across multiple providers and through intermediaries with whom we have no relationship. Continuing to believe that nobody is ‘seeing’ our packets is naïve. What we can do is ensure the packets themselves contain only secret, protected data. Designing protocols to provide this protection — now and into the future — is both costly and time-consuming. With emerging quantum computing threats to public–private key cryptography, even this protection may not be as guaranteed as we would like.

Even protected packets, however, reveal information. Traffic analysis can expose patterns, and advanced machine learning can distinguish streaming, file storage, and interactive traffic from packet timing and size alone. Never treat the network as inherently secure, and never rely on it below your HTTPS or Transport Layer Security (TLS) connections to hide you from others.