ABOLTUSA Brighter Tomorrow, Together.
← All research notes

Offline collaboration

Give a repeated event the same identity and the same meaning

A retry is safe when identity, business intent, and recorded outcome stay aligned; a matching identifier alone is insufficient.

Share this article
LinkedInXFacebookTelegramWhatsApp

What the identifier cannot promise

Do not assume that an unchanged identifier guarantees an unchanged effect. Imagine a refund request for 100 euros, paid in dollars using the exchange rate at processing time. Tomorrow’s retry carries the same identifier and amount, yet a fresh calculation can produce a different payout. The identifier names the request; it does not freeze its interpretation. These examples are illustrative and are not reported test results.

Freeze the agreement

Treat the governing rulebook as part of the agreement. A replay interpreted under a revised rulebook may no longer mean the same thing. Define the business operation, account scope, meaningful payload fields, and relevant rule version. Preserve any exchange rate chosen for that operation. Where both live in one database, commit the outcome record and business update together. For an external payment service, use its idempotency support where available and reconcile uncertain outcomes. Account for concurrent retries too.

Check before you trust retries

Try the same request twice, then retry after changing a relevant configuration value. Check both the returned result and the actual business effect: one refund should remain one refund. Also submit the same identifier with a different amount; reject the conflict. Normalize harmless formatting before comparing business fields. Test a crash between payment and acknowledgment. The retry should recover the recorded outcome or reconcile the payment, without issuing another refund merely because the response was lost.

Hypothetical boundary: the record has expired

Explicitly hypothetical boundary case: a refund retry arrives after the deduplication record expires, while the payment ledger still retains older transactions. Decision rule: if a durable record verifies that this request already completed, return that outcome. If the evidence is missing or ambiguous, reconcile before authorizing another payment. Assign a new identifier only to a separately approved new refund. Choose record retention around the permitted retry window, and define how later arrivals are handled.

Make the research practical.

Tell us which documents you work with and the decisions you need to make.

Share your use case ↗