Idempotence & Idempotent Design in IT/Tech Systems

Buying something online is something we’ve all done. And something I bet some of us have done —accidentally clicked the Pay Now button twice, only to be charged twice. That probably sent you down the long path of calling the company, explaining what happened, and seeking at least one refund.

But what if that Pay Now button was designed in such a way to avoid that exact, accidental situation? That’s exactly what the concept of idempotence does.

Briefly put:

• Idempotence refers to an operation that can be applied multiple times without changing the outcome beyond the initial application. In IT systems, designing something to be idempotent ensures consistent results regardless of how many times a request is repeated.
• Idempotent design focuses on creating systems where operations can handle retries or repeated executions gracefully, enhancing reliability and fault tolerance.

What is idempotence? What idempotent means

In IT and technology systems, idempotence is a property where a system can safely handle repeated events without changing its state. This capability is an ideal approach for several use cases, especially around ensuring data consistency and reliability.

Idempotent operations ensure that the outcome of an operation is the same whether it is executed once or multiple times. Let’s say the given operation is performed once with some outcome — any subsequent repeating of that operation doesn’t change the outcome beyond the initial application (unless, of course, something has changed over time). Examples of operations could be:

• Pressing a button in an app
• Making a GET or PUT request
• Performing a database operation.

If designed with idempotence, pressing a button once will only yield one result, and pressing that button over and over again will continue to yield that same one result.

The mathematical operation

Idempotence is a property of reaching a final state/outcome, and any further (repeat) operation does not change its destination, since it is already in its final state. At its essence, the property is observed in many fundamental mathematical operations (though for this article, we’re looking at idempotence through the lens of IT and tech systems, software, and apps).

Consider the following simple function:

f(f(x)) = f(x)

A function of a function produces the same state as the function applied to its original input argument, x. For example, consider the absolute value function:

f(x) = |x| (absolute value function)

e.g. f(1)=|1|=1

And if we break down f(f(1)) into intermediate steps:

f(f(1))=f(|1|)=f(1)=|1|=1

Another example:

f(-1)=|-1|=1

And so is, f(f(-1))=1

Breaking down f(f(-1)) into intermediate steps:

f(f(-1))=f(|-1|)=f(1)=|1|=1.

Notice in the last equation, absolute function |x| produces |-1|=1 and therefore, all subsequent function implementations f(x) converge to the same result, that is to say, both f(-1)=1 and f(1)=1.

The role of idempotence in the world

Essentially, idempotence is about the stability of existence within a perpetual state. Think of an elevator button as an example. Once you press a button and the elevator begins its journey to reach your floor, pressing the button repeatedly has no additional effect.

An already-on light bulb remains on when it is switched on again. A sorted set of books in the library remain in the same sequence once they are sorted completely. Sorting them any further doesn’t change their placement sequence.

Now, what happens if the idempotence property does not hold in practical use cases? It’s logical to think that a light bulb that is already turned on cannot be turned on again; sorted books cannot be sorted again.

Idempotence in software, IT systems, and websites

But what happens if you click the Pay Now button at your ecommerce store Web page? As a conceptual operation, payment can be done repeatedly —and is occasionally done so, by mistake, resulting in a double or triple charge.

To avoid these mistakes, idempotence is introduced into the systems by design within the software architecture.

Examples of idempotent design

Let’s look at some real examples of idempotence.

HTTP methods and API design

GET and PUT are very common requests in HTTP methods and API design.

• The GET request fetches data. GET is idempotent because fetching data from a server does not (and should not) alter the data on the server, regardless of repeated requests, unless the data has been changed.
• The PUT request updates a data resource or creates one if it doesn’t exist. PUT is idempotent because updating a resource with the same data will always result in the same resource state. Put another way (😉), repeated PUT requests do not produce duplicate copies of the data.

Distributed systems & retry mechanisms

In distributed systems, message queues are designed to be idempotent so that they process only unique transaction IDs — and therefore ignore any duplicates.

A common use case is for online payment systems. If a repeat payment request is received, like our example above, the application checks the transaction ID and skips it if found within the queuing system. This way, you’re only paying and purchasing once.

Infrastructure as code

In IaC, an environment is deployed with the same configuration independently of its starting state. This is achieved by either:

• Discarding existing environments and executing fresh environments with the required configurations.
• Automatically updating the configurations on existing environments.

Database operations

A query like UPDATE users SET status = 'active' WHERE id = 1 is idempotent because re-executing it doesn’t change the result.

However, INSERT INTO orders VALUES (...) may not be idempotent unless constraints (e.g., unique keys) prevent duplicates.

Characteristics and best practices of Idempotent Design

So, when designing with idempotence in mind, here are some tips to consider.

State aware

Operations and logic account for the system state variables. A stateless design system that does not rely on external environment variables can consistently identify a system state, making it easy to exhibit the property of idempotence.

Eliminate side effects

Repeat task execution — such as duplicating copies of data and repeated payment processing — should be avoided by design.

Unique identification

Eliminate any side effects by building in a search for unique identification of a transaction event. If the ID is repeated, only one transaction occurs — the rest should be ignored.

Functional idempotence

A function should be decoupled from the state variables and can be invoked without changing results from the initial execution. Redundant operations are prevented if the result is expected to be the same.

For example, if a user is active, repeat checks will not execute a repeat search of the user status in the database until the status is marked as inactive.

Atomicity and transactions

It is an all-or-nothing operation. For example, if a payment transaction halts due to a network outage, it does not simply restart later when the network goes back online. The account balance is not deducted. And if the interruption itself has no impact on the transaction process, then the transaction completes in full, notifying the user accordingly when the system is back online.

Deterministic and converging behavior

An idempotent operation does not depend on random chances, but well-defined instructions. It also contains mechanisms to converge repeat operations to the same results (example: for f(x)=|x|, the result for f(f(x)) becomes the same for x=1 and x=-1 at the node where f(-1)=1).

The operations occur in isolation but are independent from simultaneous, concurrent operations. (A perfect example here is the GET request).

When to use, when to avoid idempotent design

While it seems that idempotence is mostly a good thing, it is not necessarily right for all circumstances. Sometimes, idempotence goes against user expectations. Notice how pressing the elevator button doesn’t make the elevator reach your floor faster — yet we still press the button, hoping somehow that will make a difference.

At the same time, idempotence can give a false sense of security: it overlooks edge cases. For example, an API request may not change anything after its first execution, but if the underlying database operation has failed, it can produce inconsistent records.

FAQs about Idempotence & Idempotent