a field guide to resurrected wordsentry № 003

idempotent

/ ˌaɪ·dɛm·ˈpoʊ·tənt /
adjective · from Latin idem, “same” + potent, “able” — “the same, however often”

An operation you can run a thousand times and change nothing after the first. Press it again. Nothing. That is the point.

meet the button
exhibits

The Button

he has pressed it. it is lit. there is nothing more the button can do for him.
NO-OP
request state
the button is dark. at rest.
times pressed: 0 · elevator arrivals: 0pointless presses: 0

Press the button — or mash it; the elevator cannot tell the difference. The first press creates the request; every press after lands in the exact same state and produces the exact same result. That property has a name, stamped here in green: a safe, repeatable no-op. The car arrives precisely once, supremely indifferent to your urgency. He is not being ignored. He is being handled correctly.

committed-state digest
0x—————
uncommitted · awaiting first press
system logf(f(x)) = f(x)
$ press COMMIT to seal a request.

Lifeline of the Word

1870
Benjamin Peirce names the algebra: an x that squares to itself.

In Linear Associative Algebra, Peirce marks the elements where x·x = x — applying the operation twice lands exactly where applying it once did. He calls them idempotent: same-powered. Under ordinary multiplication only two numbers qualify, 0 and 1, the two most patient numbers there are.

mathematics
The whole idea, in three characters: x² = x.

Absolute value. Rounding a number that was already round. Multiplying by one. A function f where f(f(x)) equals f(x): once you have applied it, applying it again is a formality. The result has nothing left to learn from repetition.

1990s
The web is built on which verbs are safe to repeat.

HTTP draws a line through its methods. GET, PUT, and DELETE are idempotent — call them twice and the server lands in the same state. POST is not, which is exactly why your browser warns you before re-submitting a form. The reliability of the entire web rides on that one distinction.

databases
UPSERT: insert if absent, update if present, never two rows.

INSERT … ON CONFLICT DO UPDATE. Run it once, or run it on every retry of a flaky job — the table holds exactly one row either way. Idempotence is how a database survives a client that cannot honestly promise it pressed the button only once.

distributed systems
At-least-once delivery, finally made survivable.

Networks lose acknowledgements, so senders retry, so messages arrive twice. The trick is not to deliver exactly once — that is nearly impossible — but to make handling a message twice indistinguishable from handling it once. An idempotent consumer turns a duplicate into a no-op, and a hard problem into a solved one.

2010s
Stripe ships a header so you cannot be charged twice.

Send an Idempotency-Key with a payment and Stripe remembers it: retry after a dropped connection and you get the original result back, not a second charge. A single HTTP header standing between a network hiccup and your customer's fury. The word, doing real work, in production, right now.

now
Every retry, queue, and agent quietly leans on it.

Kubernetes reconciles toward a desired state — apply the manifest ten times, same cluster. Terraform plans, CI deploys, message queues, an agent re-running a tool after a timeout: all safe only because the operation underneath can be repeated without harm. The button has been pressed. It remains, as ever, done.