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.