Laws of Software Engineering · Principle
Principle
Idempotency
An operation should produce the same result whether you run it once or run it ten times.
How to use it. Design every operation that crosses a network this way. Retries become safe. Failure modes shrink. "Did the message arrive" stops being a panic.
How it gets misused. Treated as something only relevant to APIs. Idempotency matters for jobs, scripts, deploys, and migrations: anywhere a thing might run twice by accident.
Related
-
Law
Two Generals' Problem
Two parties communicating over an unreliable channel cannot guarantee they have agreed on anything.
-
Principle
Hyrum's Law
If your software has enough users, every behaviour they can observe will become something they depend on, even if you never promised it.
-
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.
Clusters
- The Distributed Systems cluster - The mathematics of what is possible across a network.
- The Interface Contracts cluster - What you promise, what you accept, what your users come to depend on.