An operation is idempotent when repeating it has the same intended effect as doing it once. That matters after a timeout: the caller may retry work that already succeeded. A reward-points job, for example, could grant points twice for one purchase.
This post uses a C# console project and a background worker to show how a stable key, payload comparison, and a saved receipt prevent that second grant. The demo simulates a lost acknowledgement after success, then retries the same operation.
The guarantee is limited to one shared in-memory store. Surviving restarts or coordinating separate processes requires the business change and receipt to persist in one transaction. Retention and external effects such as email need their own rules.
Read the full article on my blog: Idempotency: Make Retries Safe.
Top comments (0)