The field guide · rule 04 of 16
Make actions safe to repeat
Connections drop and people press twice. An action that runs twice should have the same effect as running once.
What it means
Connections drop, servers restart and people press the button twice. A well-built action can run twice and still have the effect of running once. The safe way is a unique number for each request, which the database refuses to accept twice, rather than hoping everyone is careful. Engineers call this idempotency.
What goes wrong without it
A payout times out, the system tries again, and the customer is paid twice.
How I build it
- My chain-intelligence service saves each transaction under its unique ID and skips it if it is already there, so reading again after a crash never makes duplicates.
- My finance back-office gives each statement import a unique key for each company and file. Running it again says "already imported" instead of counting it twice.
- In my reward systems, a withdrawal request carries its own unique key and is created in one locked step, so one click is one request, even if it is retried.
Ask your team
- If the same request arrives twice, is the second one refused?
- Does a retry first check whether the first attempt already worked?
- Is the duplicate check in the database, not only in the code?
How a review checks this
The payments check forces timeouts and repeats on purpose, and shows whether anything is ever sent twice.
Request a reviewThe offer: Payments and ledger integrity checkCheck your system in one minute