Comparison
Exactly-once processingvsIdempotency key
Exactly-once processing
you make the duplicate delivery harmless by deduplicating on a key or committing the offset in the same transaction as the result.
The property that each message affects the result exactly once. Exactly-once *delivery* over an unreliable network is impossible; exactly-once *effect* is achievable, by pairing at-least-once delivery with idempotent processing or a transaction spanning the output and the offset commit. When a vendor says exactly-once, this is what they built, and it only holds inside their system boundary.
Full entry →Idempotency key
the client sends a unique id with the payment request so that retrying it cannot charge the card twice.
A caller-supplied identifier that lets the server recognise a retry of a request it has already handled and return the original result. It is the standard way to make a non-idempotent operation safe to retry over an unreliable network. The server side needs storage with a retention window and a rule for what happens when the same key arrives with a different body.
Full entry →