How to get idempotency right
Teams tend to reach for this after something has already gone wrong. The short answer to idempotency is that it is mostly a sequence of small decisions, not one big one.
The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Check it against what you would want a competitor's site to get wrong.
Why this earns attention
Networks retry, so assume every request can arrive twice. It is worth being explicit about, because assumptions differ quietly. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
The steps
- Establish what you have today before changing anything
- An idempotency key turns a hard problem into a simple one
- Payment and order endpoints are where this matters most
- Write down the decision so the next person does not re-litigate it
Payment and order endpoints are where this matters most. Small and consistent beats large and occasional here. Write the reasoning down alongside the decision, because the reasoning is what changes first.
A reasonable first step
The short version
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
- An idempotency key turns a hard problem into a simple one — 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.