Article chapter 03 of 08
Make repeated requests refer to the same operation
From Recovering an automated workflow after a partial failure
Where an API supports idempotency, use its documented mechanism for an operation that may need retrying. The intention is that repeating the same request has no additional effect. That protection depends on the provider's actual contract, including the scope and lifetime of the identifier.
Create the operation identifier before the first attempt and retain it. A retry of that same operation must use the same identifier. Generating a new one after every timeout can make each attempt look like a separate request to the destination.
Keep the identifier specific enough to distinguish legitimate actions. A case may create an external record and later update it. Those are different operations. Conversely, two workers attempting the same approved creation should resolve to the same operation, even if their execution identifiers differ. Include the tenant or account in your local uniqueness rules so unrelated customers cannot collide.
Featonby's article also discusses a repeated request identifier accompanied by changed parameters. Preserve the approved payload, or a protected reference that can reproduce it, so a retry does not quietly send different content under the old identifier. If the requester corrects the document, decide explicitly whether that creates a new operation and whether the old one must first be reconciled.
When you control the receiving service, enforce deduplication atomically with the local change it protects. A separate "have I seen this?" query followed by an unprotected insert allows concurrent workers to pass the check together. A unique constraint and an appropriate transaction can enforce the rule within that database. They do not automatically extend the same guarantee to another service called afterwards.
If the destination has no suitable idempotency support, retain the uncertainty path. A local lock can reduce concurrent attempts, but it cannot prove that a remote request failed after the lock holder lost contact. Some cases will need manual reconciliation before another write is authorised.