CONCEPT Cited by 3 sources

Idempotent operations

Definition

An idempotent operation is one whose effect is the same whether executed once or many times with the same inputs. Idempotency is the enabling property for safe retries: without it, a retry after an ambiguous failure (timeout, connection drop) risks duplicating the side effect.

Zalando's timeouts post frames the retry-safety connection directly:

"If the operation being performed is idempotent, meaning that executing it multiple times has the same result as executing it once, retries are generally safe." (Source: )

Examples

Idempotent by nature: - GET /users/42 — reading a resource. - PUT /users/42 { "name": "Ada" } — full replacement of a resource with the same body. - DELETE /users/42 — second delete is a no-op. - SET key value in a KV store. - UPDATE users SET status='active' WHERE id=42 — the status is "active" after one write or ten.

Not naturally idempotent (see concepts/idempotent-operations): - POST /orders { ... } — each call may create a new order. - UPDATE counters SET n = n + 1 — each retry increments again. - Financial debits and transfers.

HTTP method semantics

HTTP verbs advertise intended idempotency to callers and caches:

Method	Intended idempotency
GET, HEAD, OPTIONS	Safe (idempotent + side-effect-free)
PUT, DELETE	Idempotent
POST	Not idempotent by default
PATCH	Depends on payload semantics

The advertised semantics are a contract, not a guarantee — application code is free to violate them, and many APIs have non-idempotent PUTs or effectively-idempotent POSTs. Callers should verify rather than assume.

Making a non-idempotent operation idempotent

The canonical mechanism is the Idempotency-Key header: the caller supplies a unique key with each logical operation; the server deduplicates by key and returns the original response on replay. Named references the Zalando post cites:

• Stripe — Idempotent Requests
• Amazon Builders' Library — Making retries safe with idempotent APIs

The load-bearing idea: server-side deduplication by caller-supplied key converts any write into an idempotent one from the caller's perspective.

The Zalando house-style caveat

Even when an operation appears idempotent, the Zalando post recommends confirming with the owner before enabling retries:

"Even if you think an operation is idempotent, if possible, ask the service owner whether it is a good idea to enable retries."

Reasons to ask: - Apparent idempotency may hold at the API boundary but not downstream (e.g. an idempotent endpoint that emits a non-idempotent event). - Side-effects like analytics, notifications, or audit log entries may duplicate even when the core state transition does not. - Retries may amplify load on a struggling service beyond the point a circuit breaker can catch.

Seen in

• — canonical framing as the determining property for retry-safety.

Related

• concepts/idempotent-operations — the complement; retries require additional safeguards.
• concepts/exponential-backoff-jitter — the retry- scheduling discipline once idempotency permits retries.
• retry-on-5xx-not-4xx — Zalando house-style retry policy that assumes idempotent (or idempotency-keyed) operations.
• idempotency-key-header — the contract that promotes non-idempotent writes to safely retryable ones.
• patterns/circuit-breaker — pairs with retry to avoid load amplification.

Seen in

• sources/2026-07-22-databricks-simplify-ai-agent-orchestration-with-lakebase-postgres — Idempotent webhook callbacks: the handler accepts PROCESSING or ENQUEUED states and treats already-terminal tasks as no-ops. Identical payloads produce identical results, eliminating double-billing under network retry.

• sources/2026-09-08-databricks-build-durable-agents-with-temporal-and-lakebase — Idempotency as the load-bearing contract on a durable agent's at-least-once workflow↔DB seam. Databricks' underwriting agent runs Lakebase writes as Temporal Activities, so a write can commit before completion is recorded and be retried. Idempotency is enforced three ways: (1) deterministic identities (run_id, message_id, tool_call_id, event_id, review_id, decision_id) anchored by Postgres primary keys and unique constraints; (2) guarded upserts whose predicate only permits a nonterminal row to transition to started/terminal — a retry against an already-terminal row affects zero rows and raises no error (patterns/conditional-write); (3) an explicit caveat that zero-row results must be classified, not silently swallowed — production code should treat zero as a no-op only after confirming the stored terminal state, else raise/record a conflict. Generalized rule: every side-effecting tool needs an equivalent dedup contract (payment idempotency key, email message ID, DB unique constraint), and where none exists the Activity must keep its own record or reconcile.

Merged aliases

• non-idempotent-operations- duplicate-execution-prevention
• idempotent-build-action
• idempotent-job-design
• idempotent-migration
• idempotent-thread-safe-scan-step
• request-level-deduplication- idempotency-token