Assumptions about distribution
Distributed systems communicate over networks with delay, failure and limited resources. Architecture must take these characteristics into account as normal operating conditions.
- ErrorSilent adoption over the net.
- ConsequenceWhat that means for the call.
- Design responseConcrete decision in the flow.
Context
Why this is important
Anyone who treats calls across service boundaries like local method calls quietly relies on assumptions that do not apply on the network. The eight errors according to L Peter Deutsch make these assumptions testable. Timeout, Retry and Breaker deepen their own building blocks.
This building block translates network assumptions into design questions. Timeout, Retry and Observability deepen specific protection and diagnostic mechanisms.
At a glance · Silent assumptions about the network
The Eight Mistakes in Payment Process
The shop application requests an external payment provider. The team looks at what delay, separation and variable response times mean for the flow.
This is how you read the picture
- Error The first column, such as “The network is reliable”.
- Consequence The column “Follow for the call” and the case in the shop next to it.
- Design response The last column, such as “Keep identifier, query status” if the answer is missing.
| Error | Follow for the call | Case in the shop | Design response |
|---|---|---|---|
| The network is reliable | Response may be omitted | Payment P-731 Remains without answer | Keep identifier, status query |
| Latency is zero | Response time varies and can be long | Time budget 1.000 ms; answer only came up 1.500 ms | Set time budget, show clarification |
| Bandwidth is infinite | Great answers are stuck | A call provides more order data than the page needs | Retrieve only required fields |
| The network is secure | Strangers can read or intervene | Payment data runs to the external provider | Encryption, checking callers |
| The topology does not change | Changing addresses and instances | The provider moves to another address | Resolve names, do not write addresses |
| There is one administrator. | Responsibility lies with several parties | Shop team and payment providers change independently | Version contracts and agreements |
| Transportation costs are zero | Each call costs time and resources | Many small payment requests per order add up | bundle calls, measure overall path |
| The network is homogeneous | Opposites behave differently | The provider uses different formats and error codes than the shop | Checking contracts, translating errors |
Benefits & limitations
Helps if:
- Network communication adds variable latency and partial failures to local functional dependencies.
- Chains of remote calls can propagate delays and failures along the entire path.
- Data and identity transitions across process boundaries require serialisation, access protection and version rules in the contract.
Boundaries
- The eight fallacies prompt reflection; they are not an exhaustive checklist. Examine each call across a service boundary individually.
- Protective mechanisms consume time and operational effort themselves. Timeout and retry settings need coordination to avoid making the situation worse.
- Measurements reveal whether a fallacy affects production behaviour; Observability exposes latency and aborted calls.
In practice
- Count network round trips across the entire process and combine data that belongs together in business terms into coarser-grained operations. Measure total latency as well as individual calls.
- Define failure semantics, identity and a time budget for each remote boundary. An aborted call needs a distinct outcome for the caller.
- Vary delay, loss and destination changes in tests. Timeout limits waiting time; Backpressure protects against backlogs.
Read the detailed explanation
Network calls have variable latency, can fail and transfer versioned data across a security boundary. Their failure and cost characteristics differ from calls within the same process.
Many small round trips multiply waiting times and potential failure points. Coarser-grained business operations, clear error semantics and measurable time budgets help account for these properties in the architecture.
Timeout limits waiting time; Backpressure limits offered load. Together, they turn network assumptions into concrete time and capacity budgets.
The eight fallacies originated with L Peter Deutsch and colleagues at Sun Microsystems.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Which design reaction belongs to the error “The network is reliable”?
View the solution with justification
Keep the identifier and query the status, because the answer to the payment P-731 may be omitted.
ApplyingTransferred to a new situation
The payment provider moves to a new address, and the shop no longer reaches it. What is the error behind it, and what helps?
View the solution with justification
“The topology does not change.” The shop dissolves the provider via a name, instead of specifying the address.
EvaluateWeighing an alternative
The team sets the time budget for payment calls very generously so that latency fluctuations never stand out. What speaks in favour, what speaks against?
View the solution with justification
Fewer calls cancel prematurely. On the other hand: the caller waits a long time, and the shop can only display the pending clarification late. A fixed time budget with clarification remains more controllable.
Explore further
These building blocks continue the thoughts of this page.
References
- Martin Fowler – First Law of Distributed Object Design (opens in new tab)Explains consequences of network latency and remote calls for editing services.
- AWS – Challenges with distributed systems (opens in new tab)Shows practical limits of assumptions about network, time and error detection.
- AWS – Timeouts, retries, and backoff with jitter (opens in new tab)Explains timeouts, limited repetitions, and jitter based on distributed failures.