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:
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:
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.
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.
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.
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.
Let’s look at some real examples of idempotence.
GET and PUT are very common requests in HTTP methods and API design.
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.
In IaC, an environment is deployed with the same configuration independently of its starting state. This is achieved by either:
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.
So, when designing with idempotence in mind, here are some tips to consider.
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.
Repeat task execution — such as duplicating copies of data and repeated payment processing — should be avoided by design.
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.
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.
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.
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).
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.
See an error or have a suggestion? Please let us know by emailing ssg-blogs@splunk.com.
This posting does not necessarily represent Splunk's position, strategies or opinion.
The Splunk platform removes the barriers between data and action, empowering observability, IT and security teams to ensure their organizations are secure, resilient and innovative.
Founded in 2003, Splunk is a global company — with over 7,500 employees, Splunkers have received over 1,020 patents to date and availability in 21 regions around the world — and offers an open, extensible data platform that supports shared data across any environment so that all teams in an organization can get end-to-end visibility, with context, for every interaction and business process. Build a strong data foundation with Splunk.