The Fallacy of the Perfect Network
When learning to code on a single machine, things are reliable. If function A calls function B, it almost always works. The operating system handles memory, the CPU handles scheduling, and everything runs in the same process. Failures are exceptions, not the norm.
In distributed systems, this assumption collapses entirely. Network cables get unplugged, routers crash, servers get overloaded, databases hang, and entire data centers lose power. You are no longer dealing with one machine — you are dealing with dozens or hundreds of independent processes communicating over a network that was never designed to be perfectly reliable.
The first rule of distributed systems is that failures are inevitable. This is not pessimism — it is engineering reality. The eight "Fallacies of Distributed Computing" (a famous list first articulated by Peter Deutsch at Sun Microsystems) capture this well. The very first fallacy is: "The network is reliable." Engineers who build systems assuming the network will always work eventually discover, painfully, that it won't.
What is Resiliency?
If failure is guaranteed, our goal shifts from "preventing failure" to "handling failure gracefully."
Resiliency is the ability of a system to recover from failures and continue to function, perhaps in a degraded state. It is the difference between a glass statue that shatters when dropped and a rubber ball that bounces back. A resilient system does not pretend failures cannot happen — it anticipates them and has a plan for each one.
We use a set of standard architectural patterns to build this "bounce" into our systems. These patterns are not mutually exclusive. In production systems, they are layered together: a retry sits inside a circuit breaker, which sits inside a bulkhead, which has a fallback. Understanding each pattern individually — and then how they compose — is the core skill this lesson teaches.
Key Point: Resiliency is not the same as reliability. A reliable system tries to prevent failures. A resilient system assumes failures will happen and designs for recovery. In distributed systems, you need both — but resiliency is the safety net when reliability measures fall short.