Fallacies of Distributed Computing
- Pradeep P
- 2 days ago
- 4 min read
Layer 1 · Post 16 of 21
← Previous: LLM Cost Management → Next: Little's Law
Layer 1 — The building blocks · Post 89 of 119
The eight assumptions that are false in every real network, and why they keep showing up as production incidents.
What you'll learn
The eight fallacies (Deutsch / Gosling) as a checklist, not trivia
How each one maps onto a later post in this series
Why "it worked in staging" is usually one of these, not a mysterious bug
The idea in one minute
In the 1990s, Peter Deutsch (and later James Gosling) listed eight false assumptions people make when they first write networked software:
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
Post 1 said a distributed system is independent machines plus an unreliable network. These eight are that sentence, unpacked. Every timeout, retry, TLS config, and "why did this pod's IP change" ticket is one of them coming due.
Your code assumes: call() == local function
Reality: call() == maybe, later, twice, never, or to the wrong box
Why it matters
Interviews do not need you to recite all eight in order. They need you to not design as if they were true.
A design that treats another service like a function call will look fine in a demo and fall over the first time a zone blips. Naming the fallacy is how you justify timeouts (1, 2), backpressure (3), mTLS (4), service discovery (5), multi-team APIs (6), egress bills (7), and "we cannot assume HTTP/2 everywhere" (8).
How it works
Take them one by one, as engineering, not history.
1. Reliable. Packets drop. Links die. The other process crashes after it received your request. That is retries, idempotency, and delivery guarantees.
2. Latency is zero. Same-rack is milliseconds. Another region is tens to hundreds. A "chatty" API with 40 sequential calls is a latency budget you already spent. That is Post 2, and Tail at Scale later.
3. Infinite bandwidth. You can fill a NIC, a NAT gateway, or a Kafka partition. Replication lag is often "we shipped the whole row, every time." Backpressure exists because pipes are finite.
4. Secure. The network is shared. Encrypt in transit, authenticate callers, do not put secrets in the URL. Zero-trust is this fallacy taken seriously.
5. Topology is static. Kubernetes reschedules. Autoscaling adds boxes. A load balancer target disappears. DNS TTLs lie. Service discovery exists because the map keeps moving.
6. One administrator. Your checkout team does not run payments, DNS, or the cloud account. Version skew, rate limits, and "we changed the auth header" are multi-admin facts.
7. Transport is free. Cross-AZ, cross-region, and NAT gateway bytes are a bill. Chatty designs are cost designs. LLM token streaming later in the series is the same idea with GPUs.
8. Homogeneous. Not every hop is your language, your MTU, your TLS version, or your protobuf. Gateways and contracts exist because the path is mixed.
You do not "solve" the list. You stop believing it.
A simple example
A new service calls user.get(id) in a loop to build a page of 50 authors.
On a laptop that is instant. In production:
each call is 5–15 ms (fallacy 2)
50 calls in sequence is 250–750 ms before you render
one of the 50 times out (fallacy 1)
Black Friday doubles QPS and the user service NIC saturates (fallacy 3)
a deploy moves the user pods; a stale IP is still in a connection pool (fallacy 5)
The fix is not "try/catch." It is batch APIs, timeouts, retries with idempotency, and not treating the network as RAM.
Common mistakes
Memorizing the list and still writing N+1 remote calls. Reciting Deutsch does not cache a round trip.
Assuming VPC means secure. Private is not authenticated. Identity is still a thing (fallacy 4).
Blaming "the network" as one blob. Say which fallacy: loss, delay, bandwidth, or a topology change. The fix is different.
Staging on one node. A single-machine compose file makes 1, 2, 5, and 8 look true. They are not.
How this shows up in real systems
AWS / GCP / Azure outage posts: almost always "the network was not reliable" plus "topology changed."
Kubernetes: pod IPs are ephemeral. That is fallacy 5 as a product feature.
gRPC deadlines, HTTP timeouts, Kafka request.timeout.ms: engineering against 1 and 2.
Service meshes: retries, mTLS, and outlier detection are fallacies 1 and 4 with a sidecar.
Recap
The eight fallacies are the false defaults of networked code.
Each one is a later tool in this series: timeouts, discovery, security, backpressure.
Design as if the network will lie; staging will not prove it won't.
Next: queues in numbers — Little's Law.
Layer 1 · Post 16 of 21
← Previous: LLM Cost Management → Next: Little's Law
Comments