What they are
The fallacies are assumptions that engineers wrongly bake into networked code. First named by Peter Deutsch and others at Sun, they explain why so many systems fail in production but pass on a laptop.
The list
- The network is reliable so retries and timeouts are not optional
- Latency is zero so chatty round trips are slow over distance
- Bandwidth is infinite so payload size matters at scale
- The network is secure so every link needs defense
- Topology does not change so hard coded routes rot
- There is one administrator so config drifts across owners
- Transport cost is zero so serialization and hardware add up
- The network is homogeneous so protocol mismatches appear
Why it matters
Each fallacy turns into a real incident. Assuming reliability means no retry logic. Assuming zero latency means a UI that hangs when a remote call is slow. Treating these as design inputs, not surprises, is the start of distributed thinking.
Designing against them
- Add timeouts, retries with backoff, and idempotency
- Batch calls to cut round trips
- Measure payloads and compress when large
- Encrypt links and authenticate peers
Key idea
The fallacies are a checklist of lies; assume the network is hostile and design every remote call defensively.