Idempotency for small teams

Most teams know this matters. Fewer have decided who owns it. Most advice about idempotency assumes a team that does not exist at your size. Here is the version that does not.

Most systems fail at the seams rather than inside any one component. Budget a little time for it every quarter and it never becomes a project of its own.

What to keep

Networks retry, so assume every request can arrive twice. The cost of getting this wrong is rarely visible on the day it happens. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. It is worth being explicit about, because assumptions differ quietly.

The practical version

Payment and order endpoints are where this matters most. Where this goes wrong is almost never a lack of knowledge. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

The short version

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. 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 want a second opinion on how yours is set up, ask.