sysdesign-idempotency-patterns

Make write endpoints idempotent by specifying an Idempotency-Key header and a dedup store with TTL. This implements an atomic claim-then-commit flow that blocks duplicate side effects during retries.

An atomic claim-then-commit flow works by claiming the Idempotency-Key in a dedup store before processing the write request, then committing the final response. This guarantees safe concurrent requests and duplicate prevention.

The best way to implement a dedup store is using Redis, DynamoDB, or a relational table with a TTL policy. This enables tenant-scoped key design and stores full responses for byte-equal replay on retries.

Yes, you can replay the exact same response by storing the full response payload in the dedup store. When a retried request hits the same Idempotency-Key, the system returns the stored response for byte-equal replay.

You need idempotency patterns for action-like write endpoints such as payments, shipments, orders, and notifications. These endpoints require idempotency when retries and concurrency can cause duplicate operations.