An operation is idempotent if multiple executions have the same effect as a single execution.
Why It Matters
In distributed systems, requests can be:
- Retried due to timeouts or failures
- Duplicated due to network issues
- Reprocessed after crashes
Idempotency prevents issues like:
- Duplicate charges in payment systems
- Multiple email notifications
- Inconsistent state from repeated operations
Implementing Idempotency
Idempotency Keys
- Client generates unique request ID
- Server tracks processed IDs (e.g., in Redis, database)
- Duplicate requests return cached response
Naturally Idempotent Operations
- GET: Reading data doesn’t change state
- PUT: Setting a value to X multiple times results in X
- DELETE: Deleting an already-deleted resource is a no-op
Non-Idempotent Operations
- POST: Creating resources typically generates new entities each time
- PATCH: Partial updates may compound (e.g., incrementing a counter)
Design Patterns
- Unique Request IDs: Include in API requests for deduplication
- Database Constraints: Use unique indexes to prevent duplicates
- Transaction Log: Record operations to detect and skip duplicates