Systems integration
Retryable requests need idempotency records before they feel safe
Retries are useful only when the system can tell whether a request already created the intended business result. An idempotency record gives each retry a stable key, saved request fingerprint and stored outcome so a timeout does not become a duplicate order, ticket or task.
Retries are not a business guarantee
A network timeout tells the caller that it did not receive an answer. It does not prove the system failed to create the order, ticket, reservation or job. A retry button can be helpful, but only when the receiving system can recognize that the second attempt belongs to the same original intent.
Think about a customer request that creates a service visit. The first submission reaches the server and creates the visit, but the browser loses the response. If the user submits again and the server treats the request as new, the team now has two visits to reconcile. The useful design question is not whether retry is allowed; it is how the system proves what happened to the first attempt.
Give every creating request a durable key
RFC 9110 defines idempotent HTTP methods as methods where multiple identical requests have the same intended effect as one request. Many business workflows, however, use operations that create new resources and are not automatically safe to repeat. Those operations need an application-level record.
Stripe documents idempotency keys for safely retrying POST requests, including storing the resulting status code and body for a key and comparing incoming parameters. The practical lesson is broader than payments: generate a key for one business intent, save a fingerprint of the important request fields, and return the recorded result when the same key arrives again.
Make mismatched retries visible
An idempotency key should not be a magic override. If a retry arrives with the same key but different customer, quantity, file, date or amount, the system should stop and explain the conflict. Reusing the key for a changed request hides a decision that should be made by a person or by a clearly defined rule.
Store enough detail to support the decision without turning the idempotency table into a copy of every private field. A hash of the canonical request, the actor, creation time, current status and result reference are often more useful than a large blob nobody can inspect safely.
Keep the record through the support window
The record needs a retention period that matches real retries and support questions. Too short, and a delayed mobile retry can create duplicate work. Too long, and the table becomes an unbounded operational archive. Decide how long users, scheduled jobs and support staff reasonably need the replay protection.
Also decide what happens while the first attempt is still running. Returning “still processing” may be better than starting a second worker. If the worker fails after the business write, the idempotency record should point to an exception that someone can resolve instead of pretending the request never existed.
Test the unpleasant timing cases
A happy-path test cannot prove retry safety. Test a lost response after the write, a duplicate click while the first worker is active, a retry with changed parameters, an expired key and a failed result replay. Confirm that support can search by key and find the associated business record.
The takeaway is simple: retry becomes safe when the system records intent, compares attempts and replays known outcomes. Without that record, retry is just a convenient way to multiply uncertainty.