Interactive note / Reliability
One intent.
How many effects?
The write succeeds. The response never arrives. The client has a reasonable question: “Should I try again?”
The first write succeeds, but its response is lost. Remaining requests arrive sequentially, within the key’s retention window.
| Attempt | Key | Outcome |
|---|---|---|
| Original | intent-001 | Write committed; response lost. |
| Retry 1 | intent-001 | Stored result reused; no new effect. |
| Retry 2 | intent-001 | Stored result reused; no new effect. |
The key identifies the intent, not the delivery. Reusing it lets the service recognize this operation.
The difficult part is the boundary.
This model assumes a durable, atomic record of the key, result, and effect. A browser-side Set is enough to illustrate the idea, but it is not a production implementation.
Same intent, same key
A retry reuses the original key. A new operation gets a new key. Reusing a key with a different payload should be rejected, rather than quietly returning an unrelated result.
The limits matter
Concurrent requests, key expiry, crashes, and effects outside the transaction need separate treatment. This experiment models sequential deliveries only; it does not demonstrate universal “exactly once” execution.
Beyond the model
What if the worker crashes after the external effect, but before recording success?
That question changes the design. It is where the guarantees of your database stop, and the contract with the downstream system starts.
Further reading: Making retries safe with idempotent APIs — Amazon Builders’ Library