A distributed system is a collection of assumptions connected by a network.
Design around latency, partial failure, ordering, and ownership—not the happy-path diagram.
Interpretation
Boxes and arrows make distribution look orderly. Runtime behavior is not. Every remote call adds delay, uncertain delivery, version drift, and independent failure. Good architecture makes those assumptions explicit, assigns ownership, and chooses what happens when—not if—one of them proves false.
Practice
- Write timeout and retry policies beside every remote dependency.
- Define idempotency and message ordering explicitly.
- Test partial failure, not only total outage.
Anti-pattern
Treating a successful network call as the only possible outcome.