Begin with the interrupted request
A customer clicks submit, the network stalls and the interface offers a retry. The customer cannot tell whether the original operation completed. Design the server around that uncertainty. For a paid booking, the business requirement is one intended reservation, even if several requests arrive. Disabling a button improves the interface but does not resolve duplicate requests from retries, multiple tabs or background workers.
Identify the business operation
Decide what makes two requests attempts at the same action. An idempotency key can identify a logical operation, but its lifetime and storage need deliberate design. Reusing a key for a different purchase is not the same as retrying the original purchase. Define how conflicting parameters are handled and how a caller obtains the original result. Stripe’s API documentation provides a concrete example of an idempotent request contract.
Map the local and external steps
Suppose an application creates an order and then calls a payment provider. A provider-side key does not automatically prevent duplicate local orders. Write the sequence down and identify where durable state records the operation. Decide how concurrent requests are coordinated and how incomplete work is reconciled. The design should explain what happens after a process restart, not only while one server instance remembers the request.
Test the ambiguous outcomes
Use a synthetic order and simulate a timeout before the response reaches the caller. Repeat the request with the same operation identity and inspect the stored outcome. Also try simultaneous requests, a changed payload and a new legitimate order. Confirm that the system preserves the distinction between replay and new work. Tests should examine records and fulfilment, not merely whether the second response uses the same status code.
Write down the remaining limits
Document expiry, retention and recovery rules for operation records. Decide how support can safely resolve an incomplete operation without creating a second one. Avoid promising exactly-once behaviour across every component unless the design and evidence justify it. The useful release question is narrower: for the failures you expect, can the customer retry without receiving duplicate consequences, and can the team identify exceptions that require intervention?
Sources & further reading
Reference material for the guidance and examples above. Where included, community discussions provide context rather than verified incident evidence.
Prepared with AI assistance. Examples are illustrative and are not client case studies.
About CodeSignOff Editorial
CodeSignOff Editorial publishes engineering guidance for founders evaluating AI-built software. CodeSignOff is a product of Avi Root Info Solutions, led by Shekhar Juneja, whose software career began in 1998 and includes architecture for UK mortgage and credit-rating systems. This organisational byline does not indicate a personal review of this article by Shekhar.
Engineering background and editorial approach · Shekhar’s professional profile ↗
Evidence to take into your own review
Define the code revision and scope. For each finding, record the affected flow, the steps that reproduce it, its business consequence and the evidence for the next action. After a fix, repeat the check and record what remains uncertain. An audit delivers a verdict; remediation and verification are separate steps.
This article is general engineering guidance. It does not establish the security or compliance of your application. Contact us with a correction or a question about the guidance.