KNOWLEDGE / Distributed Systems / Reliability
Idempotency in Distributed Systems
How to make repeated delivery safe when networks and workers fail in inconvenient ways.
Distributed SystemsReliabilityQueues
- DOMAIN
- Backend Engineering
- LEVEL
- Intermediate
- READ
- 8 min
- UPDATED
- Aug 22, 2026
MENTAL MODEL / KEY IDEAS
Keep these in mind
- 01Duplicate delivery is normal
- 02Choose an idempotency boundary
- 03Persist the decision atomically
Why duplicates happen
A producer can time out after a server commits, or a queue can redeliver after a worker crashes. Neither side can always know whether the effect happened.
- Client retries
- Broker redelivery
- Worker recovery
The idempotency key
A stable key identifies the logical operation. The service stores the key and result in the same transactional boundary as the business effect.
- Scope keys carefully
- Define retention
- Return the original outcome
Limits
Idempotency does not create exactly-once delivery. It creates repeat-safe behavior inside a boundary you can define and test.