Idempotency¶

Operations that produce the same result regardless of how many times they execute enable safe retries in unreliable networks, making exactly-once semantics achievable through at-least-once delivery plus idempotent handlers.

Tension Addressed¶

Latency vs. Correctness (enables aggressive retries without correctness risk)

Recognizable As¶

Idempotency keys in APIs; PUT vs POST distinction; "upsert" operations; deduplication tables; request identifiers passed through systems

Canonical Sources¶

Helland, "Life Beyond Distributed Transactions" (2007); Kleppmann, "Designing Data-Intensive Applications" (2017)

Transfers To¶

API Design (idempotent endpoints), Event Processing (exactly-once semantics), Database Design (upsert patterns), Payment Systems (duplicate protection)

Idempotency is foundational because networks are unreliable: messages can be delivered zero, one, or multiple times. Rather than solving the impossible problem of guaranteed exactly-once delivery, idempotency reframes it: if receivers can safely handle duplicates, senders can retry freely until acknowledgment arrives.

Sub-concepts: - Idempotency Keys: Client-generated identifiers enabling server-side deduplication - Natural vs. Artificial Idempotency: Some operations are inherently idempotent (set absolute value); others require explicit design (use key-based upserts instead of blind inserts)