Rule 19 of 38 · Chapter III — Make Failure Visible
Assume the network will betray you
Why this rule exists
The network is not your program. Calls that look like local function invocations cross machines, links, and load balancers that drop, delay, reorder, and duplicate messages. Code that assumes a call either succeeds or fails cleanly will eventually meet the third case — the timeout where you genuinely do not know — and if you have not planned for it, you will corrupt state or lose work.
In practice
Set explicit timeouts on every remote call; a call with no timeout is a hang waiting to happen. Make retried operations idempotent so a duplicate is harmless, and use retries with backoff rather than tight loops. Treat partial failure as normal: decide in advance what happens when the second of two writes fails.
When it doesn't apply
Within a single process or across a trusted local socket, the failure modes are narrower and heavy resilience machinery is overkill. Match the effort to the actual distance and reliability of the hop.