Partial Failures & the Fallacies of Distributed Computing

Single machine vs distributed

On one host, failure is mostly binary: the process is up or down. In a distributed system, partial failure is normal — one replica is slow, one AZ is unreachable, one message is duplicated. Your design must assume components fail independently while others keep running.

Failure modes (interview vocabulary)

Failure	What happens
Crash	Node stops; others may not notice immediately
Omission	Messages dropped (network, overloaded receiver)
Timing / performance	Node or link is slow — indistinguishable from crash without timeouts
Byzantine	Node behaves arbitrarily wrong — rarely assumed in backend interviews unless crypto/blockchain

Cascading failure — one slow dependency backs up callers; thread pools exhaust; the blast radius grows. Timeouts and backpressure exist partly to limit this (Concurrency roadmap covers single-machine sync; here the failure crosses the network).

The eight fallacies (know the top four)

Peter Deutsch's fallacies — statements that are false in distributed systems:

1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn't change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous

Interviewers use these to probe whether you design for retries, timeouts, idempotency, and explicit failure handling — not whether you can recite all eight.

What you already know from sibling tracks

• Networking — TCP retries, DNS TTL, partitions at the transport layer.
• OS — processes, scheduling, clocks that drift.
• Concurrency — races on one machine; distributed systems add independent failures and no shared memory.

Senior signal

Say "partial failure" instead of "the service went down." Distinguish unavailable (can't reach a quorum) from degraded (stale reads allowed). That's the mindset every later topic builds on.