Developer
How do you build a credit and debit path that survives retries?
The failure that turns a delivery bug into a financial one.
The answer
Key every write to the event that caused it rather than to the moment it arrived, store that key with a uniqueness constraint the database enforces, and make the second attempt return the first attempt’s result instead of performing the work again. Retries are not an edge case — clients retry, queues redeliver, and agents retry at machine rate — so exactly-once has to be a property of the ledger, never a promise made by the caller.
Where the key comes from
From the causing event: the order that was placed, the quest that was completed, the trade that was captured. A UUID minted at request time is not an idempotency key — it changes on retry, which is precisely when you need it not to. The key must be derivable by the caller a second time without coordination.
What the constraint has to be
Enforced by the database, not checked by the application. A read-then-write check is a race with a window measured in milliseconds, and two retries arriving inside that window is exactly the scenario the key exists to survive. A unique index on the key is the whole mechanism; the application logic around it is convenience.
What to return on the duplicate
The original result, not an error. A caller retrying because it never saw the first response is behaving correctly, and answering it with a conflict pushes the reconciliation problem back into a client that has less information than the ledger does.
Talk to the practice
Tell us what you are trying to build and what has to be true for it to work.
Contact