State and recovery
Sending the same request twice has the same effect as sending it once — the single most valuable property in anything that touches money.
Also called Idempotent operation · Идемпотентность
Networks lose responses, not requests. A payment call that times out has, from the caller's side, an unknown outcome: it may have succeeded and lost the reply. The only safe response is to retry, and the only way retrying is safe is if the receiver recognises the repeat and returns the original result rather than doing it again.
The mechanism is unglamorous and small. The caller generates a key for the intent — one key per booking attempt, not per HTTP call — and sends it with every retry. The receiver records the key with the outcome, and on a repeat returns the recorded outcome without re-executing. Perhaps thirty lines, and it is the difference between a duplicate-charge incident and a retry nobody notices.
It is also the property that makes everything above it recoverable. Queues that redeliver, webhooks that fire twice, a customer who double-clicks, a batch rerun after a crash — each is a duplicate the system must survive, and there is no version of any of them that is safe without this.
A key derived from the payload changes when a retry differs by a timestamp, and two genuinely separate purchases of the same item by the same customer collide. The key belongs to the thing the user is trying to do, generated once before the first attempt and reused across every retry of it. Get that wrong and the mechanism either fails to deduplicate or blocks a legitimate second order — and the second failure is the one that reaches a complaint.
The definitions are the easy part. Whether the figure on your dashboard was computed this way is a different question, and usually the more expensive one.