Idempotency, Safety and Natural Idempotency — Idempotency & Retry-Safe Systems

An operation is idempotent if performing it multiple times has the same effect on server state as performing it once (responses may differ, e.g. DELETE returns 204 then 404). Safe operations have no side effects at all. Many operations can be made naturally idempotent: set absolute values instead of relative ones (status = 'shipped' vs count = count + 1), use upserts keyed by a natural or client-generated ID, and use conditional writes. When an operation is inherently non-idempotent (charge a card, send an email), add deduplication with an idempotency key.

Idempotency of common operations

Operation	Naturally idempotent?	Make it retry-safe by
SET status = 'shipped'	Yes	—
balance = balance - 10	No	Dedupe by transaction id
INSERT order	No	Client-generated id + unique constraint, or idempotency key
UPSERT by natural key	Yes	—
DELETE /items/7	Yes	Treat 404 as success
Send email / charge card	No	Idempotency key + stored result

SQL

-- Relative (NOT idempotent)
UPDATE accounts SET balance = balance - 1000 WHERE id = 42;

-- Deduplicated by a unique transfer id (idempotent)
INSERT INTO ledger (transfer_id, account_id, amount) VALUES ('tr_8f2', 42, -1000)
ON CONFLICT (transfer_id) DO NOTHING;

-- Absolute + conditional (idempotent)
UPDATE orders SET status = 'shipped' WHERE id = 7 AND status IN ('paid', 'shipped');

Common pitfalls

Calling PATCH idempotent when it appends or increments.
Treating DELETE's 404 on retry as a failure.
Client-generated IDs without a unique constraint.

Key points

Same effect, not same response
Prefer absolute updates and upserts
Dedupe inherently unsafe actions

Further reading: RFC 9110: Idempotent methods

Practice questions

Is DELETE still idempotent if the second call returns 404?

Answer

Yes. Idempotency is about server state after the calls, not identical responses; the resource is gone either way.

How do client-generated IDs make creation idempotent?

Answer

The client chooses the ID (e.g., UUIDv7) and retries with the same one; a unique constraint turns duplicates into no-ops or conflicts that return the existing resource.