Engineering · Published October 5, 2026
Idempotency: Duplicate Submissions Are Not Just Double Clicks
Retries, redelivery and impatient users all send the same request more than once. Idempotency belongs in the API design.
Any team that has built payments has met a double charge. The visible cause is a user clicking twice; the real cause is an interface that cannot tell a second request from a new one.
Where duplicates come from
Double clicks are the simplest case. Disabling the button covers most of them, but not retries at the network layer.
Gateway resends after timeouts, at-least-once message delivery and reruns of compensation jobs are all routine on the server side.
On weak mobile networks a request may arrive while the response is lost, and the user will submit again.
Three implementations
A business unique key plus a database unique index: order number, serial or a client-generated request id. Duplicates are rejected outright.
State machine validation: only records in a given state can advance, and completed operations return the previous result.
A deduplication table storing request id and outcome, useful across service boundaries.
Idempotency is not an optional optimisation; it is part of the interface contract. One extra thought at design time saves one reconciliation later.
Want to apply these ideas to your project?
We are happy to go deeper into implementation details, or to discuss the specific questions you are facing.
Start a conversation →