Signs it is time to revisit idempotency

Teams tend to reach for this after something has already gone wrong. A few signals that idempotency is due some attention.

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. Budget a little time for it every quarter and it never becomes a project of its own.

The signals

• Nobody can say when it was last reviewed
• The answer depends on who you ask
• Networks retry, so assume every request can arrive twice
• An idempotency key turns a hard problem into a simple one

How to approach it

Payment and order endpoints are where this matters most. That sounds obvious written down. It is still the thing most often skipped. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

How to tell if yours is fine

Most systems fail at the seams rather than inside any one component. 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

The point is not perfection, it is knowing which of these you have consciously chosen to skip.