What idempotency means here

Processing the same message twice leaves the same state as processing it once. That is the definition, and everything else in this module is how to achieve it. IT IS A PROPERTY OF THE DESIGN, NOT A SETTING TO ENABLE. There is no switch. It is achieved by a correlation key, a uniqueness constraint, and a decision about where the check lives — and an integration either has it or does not. Some operations are naturally idempotent and cost nothing. A read. A delete. An update that SETS an absolute value — "set the status to approved" produces the same state however many times it runs. Some are naturally NOT, and they are the ones integrations mostly do. A create. An update that CHANGES a value relatively — "add 10 to the balance" is a different number every time. THE PRACTICAL DESIGN RULE THAT FOLLOWS: prefer absolute to relative wherever…

In this module: Module 9 · Idempotency and duplicate prevention

1. 1Why every integration is retriedFree preview
2. 2What idempotency means here
3. 3Choosing a correlation key
4. 4Where to enforce it
5. 5When the target has no natural key
6. 6Timeouts: the ambiguous outcome
7. 7Idempotency across a whole file
8. 8What breaks: three duplicate scenarios
9. 9Lab briefing · Make a payment flow safe to retry