idempotent receiver pattern
When clients retry on uncertain failure, the server keeps a record of recent request ids and returns the original response on a duplicate, rather than re-executing. Server side of the idempotency-key contract.
When clients retry on uncertain failure, the server keeps a record of recent request ids and returns the original response on a duplicate, rather than re-executing. Server side of the idempotency-key contract.
symptoms
- duplicate writes from retries
- side effects fired twice
causes
- unsafe retries with non-idempotent endpoints
- no server-side dedup
fixes
- client supplies idempotency key
- server stores key → response for some TTL
- reject duplicates or return cached response
you might say
- idempotent receiver
- dedupe on server