The ambiguity
A client sends a request. The service commits the write, but the response never reaches the client. From the caller’s point of view, the operation timed out. From the service’s point of view, it succeeded.
Retrying is reasonable. Treating every retry as a new operation is where a second effect can appear.
Open the interactive experiment to compare a missing key, a stable key, and a fresh key on every attempt.
Identify the intent
A key identifies the operation the caller intended to perform. Retries of that operation reuse the key. A new operation gets a new key.
POST /operations
Idempotency-Key: intent-001
A repeated request with the same key and a different payload should be rejected. Returning an unrelated stored result would hide an integration bug.
Where the guarantee ends
The experiment assumes the key, result, and effect are stored atomically and durably. Its local Set illustrates deduplication; it is not a production storage strategy.
Real implementations also have to address concurrent requests, key expiry, crashes, and effects outside the transaction. Writing a record locally does not make a remote side effect atomic.
If a worker crashes after the external operation succeeds but before recording that success, a local key alone cannot tell the next worker what happened. The downstream contract and reconciliation strategy matter.
What this demonstrates
The model runs sequential deliveries with a deliberately lost first response. It makes one narrow point visible: requests and effects are different quantities.
It does not establish a throughput benchmark, simulate concurrency, or prove universal exactly-once execution.