Getting started with idempotency
Every audit we run turns up some version of this. A short on-ramp to idempotency for teams who have not touched it before.
Most systems fail at the seams rather than inside any one component. It is the sort of thing that looks like polish right up until it costs you an enquiry.
Why it matters
Networks retry, so assume every request can arrive twice. The teams that handle this well are rarely the ones with the biggest budgets. If two people in the business would answer this differently, that gap is the actual problem.
Your first week
- Find out what is already in place
- An idempotency key turns a hard problem into a simple one
- Change one thing and measure it
Payment and order endpoints are where this matters most. Where this goes wrong is almost never a lack of knowledge. Check it against what you would want a competitor's site to get wrong.
In practice
Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. Three things worth confirming about idempotency before you move on:
- Someone can say what the current setup is without going to look
- Networks retry, so assume every request can arrive twice — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If you are not sure where your systems currently stand on this, it takes us about an hour to find out.