the fallacies of distributed computing

networkingcloudprogramming

The eight assumptions every distributed-systems novice makes, starting with 'the network is reliable', catalogued at Sun in the 1990s.

Peter Deutsch and colleagues at Sun, with James Gosling adding the last, listed what newcomers wrongly assume: the network is reliable, latency is zero, bandwidth is infinite, the network is secure, topology does not change, there is one administrator, transport cost is zero, and the network is homogeneous. Every timeout bug, thundering herd, and split-brain is one of the eight collecting its debt. The list is this site's home turf condensed to a paragraph: networks fail, and honest systems are designed by people who believe it.

The fallacies of distributed computing are a list, originating at Sun Microsystems, of assumptions that people building networked systems make without noticing: the network is reliable, latency is zero, bandwidth is infinite, the network is secure, topology does not change, there is one administrator, transport cost is zero, the network is homogeneous.

Each one is false and each is easy to assume because it is true enough during development. On a laptop, a local call and a remote call look identical in the code, so the difference only appears under conditions the developer never saw: a partition, a slow link, a middlebox rewriting something, an administrator in another company changing a route. The abstraction that makes remote calls look local is convenient and it is exactly what hides the failure modes.

The practical response is to design for the failures rather than to be surprised by them. Timeouts on every remote call, retries that are idempotent so a duplicate is harmless, circuit breakers so a failing dependency does not take you with it, and a clear position on what your system does when a dependency is simply unreachable. The list is thirty years old and every generation of distributed technology rediscovers it.

Also known as: the eight fallacies

← All glossary entries