Article of the day
Idempotency pattern
A payment request can time out even after the server has successfully processed it. Since the client can't tell whether the operation completed, it retries the request. Without idempotency, that retry can result in the customer being charged twice.
The solution is an idempotency key. For every payment, the client generates a unique identifier (typically a UUID) and sends it with the request. The server stores that key and the payment result within the same database transaction. If the client retries using the same key, the server returns the previously stored response instead of executing the payment again.
Idempotency keys shouldn't be stored forever. They should remain valid for at least as long as clients are expected to retry. A 24-hour TTL is a common default, balancing protection against duplicate requests with storage efficiency.
For production systems, every state-changing endpoint should require an idempotency key. Replayed requests should be checked before rate limiting since they're retries rather than new operations. Expired keys should be cleaned up periodically using a TTL, with an index on the expiration column to make cleanup efficient. The idempotency record should also maintain states such as PENDING, COMPLETED, and FAILED to handle retries and failure scenarios correctly. Finally, a reaper can safely remove requests that remain in the PENDING state beyond the expected request timeout, preventing abandoned operations from blocking future retries.
Read full article 👉 [LINK]
@devwitheyob
#TechVibe #ArticleOfTheDay #IdempotencyPattern #DistrubutedSystems
Forwarded fromTechVibe
1July 21, 2026 112
