Laws of Software Engineering

The Distributed Systems cluster

The mathematics of what is possible across a network.

Why these together

CAP, Two Generals, and FLP describe the formal limits. Ashby explains why you cannot control what you cannot model. The Fallacies list the assumptions developers make and should not. Idempotency is the practical move that makes most of this survivable. Read together, they explain why distributed systems are hard at the level of theorems as well as at the level of bugs.

• Law CAP Theorem When part of a distributed system is cut off, you must choose between consistent data and available service.
• Law Two Generals' Problem Two parties communicating over an unreliable channel cannot guarantee they have agreed on anything.
• Law FLP Impossibility In a distributed system where any one node might fail, you cannot guarantee that all working nodes will agree on a value within a fixed time.
• A Law Ashby's Law of Requisite Variety Only variety can absorb variety. A controller must be able to handle at least as many distinct states as the system it is trying to control.
• Principle Fallacies of Distributed Computing Eight things people wrongly assume about networked systems: the network is reliable, there is no delay, bandwidth is unlimited, the network is secure, the topology never changes, there is one administrator, moving data is free, the network is uniform.
• Principle Idempotency An operation should produce the same result whether you run it once or run it ten times.