Idempotence

One of the core principles of designing good software systems is composability, the idea being that it should be easy to combine and reuse different components. This has all sorts of benefits, but one of the most important is that it becomes possible for programmers to understand a complex codebase as the composition of simple parts and their interactions. Without some degree of composability and modularity, it would not be possible to build reliable systems over the course of years involving hundreds of engineers because the code simply becomes too complex to understand. Fortunately, people have gotten better at doing this, and a key part of making components easy to compose is the concept of idempotence. It is the simple idea that, when possible, functions should be written in such a way that when you call them multiple times in succession with the same arguments the result does not change. For example, putting a value in a set is idempotent while appending to a list is not since in the latter case the list will keep growing with each append.

Here's an example of an interface which is not guaranteed to be idempotent (BadService) and the resulting attempt to deal with two instances of that interface:

	trait BadService {
	// calling start or stop twice consecutively can result in inconsistent state
	// either method made fail out with an exception
	def start
	def stop
	}
	class BadServiceManager(serviceA: BadService, serviceB: BadService) {
	private var aStarted = false
	private var bStarted = false
	def start {
	serviceA.start
	aStarted = true
	serviceB.start
	bStarted = true
	}
	def stop {
	if (bStarted) serviceB.stop
	if (aStarted) serviceA.stop
	}
	}

view raw BadServiceManager.scala hosted with ❤ by GitHub

Here, the BadServiceManager is responsible for starting and stopping two BadServices. As you can see, it requires some very ugly state-management that only gets worse as you have more and more components to bring together. The natural way that this should happen with idempotence guarantees is as follows:

	trait GoodService {
	// calling start or stop twice consecutively is ok
	// either method made fail out with an exception
	def start
	def stop
	}
	class GoodServiceManager(serviceA: GoodService, serviceB: GoodService) {
	def start {
	serviceA.start
	serviceB.start
	}
	def stop {
	serviceB.stop
	serviceA.stop
	}
	}

view raw GoodServiceManager.scala hosted with ❤ by GitHub

In terms of local systems, reduced complexity is the primary reason that you would like idempotence. If that is not compelling enough, as soon as we start working with distributed systems the benefits become very clear cut. Consider a remote procedure call (RPC) made by machine A to machine B. Machine A receives a network timeout while making the call and is now in a predicament; did machine B execute the call or not? This is a very difficult question to answer generically, but idempotence can help. In the case of a network timeout, machine A simply retries the RPC until it receives a successful response from machine B because idempotence guarantees that any repeated calls will not affect the state. This greatly simplifies the job of the RPC client and makes it very natural for distributed components to communicate with each other robustly.

Understanding idempotence is an effective way to improve the composability and reliability of code. Unfortunately, it is not always easy to make functions idempotent and the restriction can make interfaces less clean. The benefits, however, manifest themselves very clearly when you do not need to deal with the unpredictability and complexities of calling non-idempotent interfaces, especially in a distributed setting.