Idempotency keys make retries safe

A client sends a payment, the region fails before the response arrives, and the client cannot tell whether it went through. Retrying may charge twice, and giving up may drop an order the user believes they placed. AWS's view is that an API with side effects is not safe to retry unless it provides idempotency.

The usual way is an idempotency key: a unique value the client attaches to every state-changing request and reuses on each attempt at the same operation. The server checks a store of keys it has seen: an unknown key is processed and recorded, a known one gets a valid response without the work being done again. Keys can expire after an hour or a day.

Ian Gorton names the part a failover tests. The state change and the stored key must both happen or neither: keep the effect but lose the key, and a retry applies it twice. Keeping keys in the same transactional database as the data gives that, and it means a lossy promotion loses both together, so the retry reapplies a write that really was lost.

With that in place, retries stop being a correctness risk and remain a load problem. Where the authoritative copy lives elsewhere, the same property lets a design send each write to every region instead of replicating it.