You have probably pressed an elevator button once and still felt uneasy enough to press it a few more times. Even if the light is already on, pressing again does not bring two elevators. On the other hand, you may have double-clicked a button in an online checkout window and worried that you would be charged twice. The concept that explains why the same kind of action is safe in one case and dangerous in the other is idempotence.
Idempotence means that doing an operation once or many times leaves you with no further change beyond the result of the first time. Put simply, “doing it again does not make something already finished grow larger,” and it is treated as especially important in the computer world, where connections drop and requests are often duplicated.
In this piece we will look, in order, at where the name idempotence came from, how everyday examples split, how HTTP turns the idea into a promise, and the designs and common misunderstandings around handling duplicate requests safely.
The Logic of Actions That Are the Same Once or Twice
A Name That Means “Same Power,” Borrowed from Mathematics
The term is known to have been coined in 1870 by the American mathematician Benjamin Peirce in a paper on Linear Associative Algebra. It joins idem, meaning “the same,” with potence, meaning “power,” so it literally means “having the same power.” Peirce gave the name to algebraic objects that remain themselves when squared or raised to any higher power.
(1) Mathematical definition
It means that applying a function f twice yields the same result as applying it once, written f(f(x)) = f(x).
(2) Representative functions
Absolute value, the floor function that drops digits after the decimal point, the ceiling function, and the identity function that returns its input unchanged all have this property.
(3) The meaning that crossed into computing
Even an operation with side effects is called idempotent if the system state after many calls is the same as after a single call.
The point to watch is that the criterion is not “the response is the same” but “the state does not change any further.” Miss that difference and you keep confusing idempotence with other ideas.
Sorting Idempotent from Non-Idempotent with Everyday Buttons
An elevator call button or a crosswalk button enters a “requesting” state on the first press, and further presses do nothing until that request is handled. A door-close button also closes on a fixed schedule, so pressing it many times is the same. A door-open button, however, lengthens the wait each time you press it, so it is not idempotent.
- Lookup: Reading a customer’s name and address does not change the data, so it is idempotent.
- Assignment: A request to set an address to a particular value leaves the final address the same no matter how many times it is sent, so it is idempotent.
- Order Placement: A request to place an order can create as many orders as the number of times it is sent, so it is not idempotent.
- Cancellation: A request to cancel a particular order leaves the order in a canceled state no matter how many times it is sent, so it is idempotent.
Even the same “button press” splits in fate depending on whether the action sets a state or adds something to a state.
The Promises HTTP Sets for Each Method
HTTP’s standard document (RFC 9110), the web’s protocol, defines a method as idempotent when the intended effect on the server of sending the same request many times is the same as sending it once.
(1) Read requests
GET, HEAD, OPTIONS, and TRACE are safe methods that only request a read, and all of them are idempotent.
(2) PUT and DELETE
PUT sets the target’s state to the content sent, and DELETE removes the target. The finished state is the same no matter how many times they are sent, so they are specified as idempotent.
(3) POST and PATCH
POST leaves how the content is processed to the receiver, so sending it twice can create two orders. PATCH also does not guarantee idempotence.
Where this distinction is used in practice is retries. When a connection drops and the response cannot be read, an idempotent request may be resent automatically by the client, but for a non-idempotent request the standard recommends against automatic retry unless there is a way to know the original request was not applied. Idempotence is also not a promise that the response is the same, so a second delete may return a “not found” response unlike the first, and that is fine.
Designs for Duplicate Requests and Common Misunderstandings
So what do you do when you have no choice but to resend a non-idempotent POST? A widely used approach is an idempotency key that attaches a unique value to each request. The payment service Stripe lets you put an Idempotency-Key header on a request. The key may be up to 255 characters, a random UUID is recommended, and a request that comes again with the same key returns the first request’s status code and body as they were. Keys may be cleared after at least 24 hours, and a different body with the same key is treated as an error. Event-processing systems that produce the same result even when a message arrives more than once stand on the same idea.
- Response: Idempotence does not mean the response is the same; it means the server’s state does not change any further.
- Side Effect: It does not count things like the server logging the request; only the intended effect is the criterion.
- Composition: Chaining idempotent steps does not guarantee that the whole is idempotent.
- Example: When a variable is 3, running “read, set to 5, read” once yields 3 and 5; the second time it yields 5 and 5.
Making it safe to press twice is a matter of designing the system to be safe on its own, instead of relying on the user’s caution. Designing the action from the start so that doing it again yields the same result—that is the first step of idempotence.
