First, the key terms.

Idempotency key
A stable identifier for a logical operation under an API’s documented rules.
Backoff
Increasing or spaced retry delays to reduce repeated pressure.

The idea, explained

A timeout means the caller does not know whether the server completed an operation. Blindly retrying can duplicate a payment or notification. A robust design records a stable operation key and its result, binds the key to the request and handles concurrent attempts atomically. Expiry and provider behavior must be understood. Retry backoff reduces pressure but does not itself prevent duplicate side effects.

STEP 1

Do not equate timeout with failure

A caller may lose the response after a server completed the action. Retrying as a brand-new operation can then repeat it. A safe protocol must distinguish repeated attempts from genuinely new requests.

STEP 2

Bind identity to intent

Store the operation key with relevant inputs and the result. Reusing one key for different purchases is also wrong. Concurrent attempts and retention periods must follow a clear, atomic policy.

Follow a worked example.

A payment request times out after the provider accepts it. The client retries with the same key. A correctly implemented provider returns the existing operation instead of creating another charge. A different purchase must receive a different key.

Walk it through, one step at a time

  1. Purchase P is sent with key K. The response times out after the provider creates the charge.
  2. Retry P with K. A correctly supported idempotency mechanism returns the existing operation rather than creating another.
  3. A separate purchase Q gets a new key. An identical price does not make Q the same logical purchase.

Where people get stuck

“Retry only once” limits duplicates but does not make an operation idempotent.

Now try it yourself.

Pause before opening each answer. Explain your reasoning in your own words.

1. Check the core idea

Should each retry of the same logical purchase receive a new idempotency key?

Reveal the answer & reasoning

No. Reuse the key for that logical operation; otherwise the receiver may treat the retry as a new purchase.

2. Apply what you learned

Does waiting five seconds before retrying prevent duplicate charges?

Reveal the answer & reasoning

Not by itself. Waiting can reduce load, but only an appropriate identity and side-effect protocol addresses the ambiguous completed-first-attempt case.