A practical checklist for idempotency

This is cheap to get right at the start and expensive to retrofit. Run through this the next time idempotency comes up.

Most systems fail at the seams rather than inside any one component. The version that survives contact with a real deadline is the simple one.

The checklist

• Networks retry, so assume every request can arrive twice
• An idempotency key turns a hard problem into a simple one
• Payment and order endpoints are where this matters most
• Someone is named as the owner
• There is a date to review it again

What it costs to ignore

Networks retry, so assume every request can arrive twice. The teams that handle this well are rarely the ones with the biggest budgets. Doing this properly once is usually cheaper than doing it approximately three times.

What this looks like day to day

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
• Payment and order endpoints are where this matters most — 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.