Idempotency Ledger

A write commits, its reply disappears, and the caller tries again. Follow the retry into a bounded idempotency ledger.

TryIn Reply gets lost, switch the ledger off. Turn it on for Retry after expiry; compare retention above/below 2,200 ms.

Watch forWith the ledger on, the first delivery creates a receipt. The next two retries replay it, so only one business effect is recorded.

Jump to the model

Separate teaching model

The linked story describes related work; the scenarios and results here are synthetic.

Interactive model

A request may commit even when its reply never reaches the caller. This small deterministic exercise separates repeated delivery from repeated business effects; it does not model a production payment or webhook service.

Choose the retry story

Retry scenario

Ledger retention1,500 ms

Request deliveries

At-least-once attempts in this scenario

Business effects

Orders actually created by the model

Responses replayed

Retries answered from the retained receipt

Key conflicts

Same key, different request fingerprint

ONE KEY · MANY ATTEMPTS

Delivery journal

Attempt 01 · 0 ms
Business effect committed
201 · receipt #1 · reply lost in transit
Key order-42:create · Request body: 2 × field camera kits
Attempt 02 · 250 ms
Stored response replayed
201 · receipt #1 · replayed
Key order-42:create · Request body: 2 × field camera kits
Attempt 03 · 700 ms
Stored response replayed
201 · receipt #1 · replayed
Key order-42:create · Request body: 2 × field camera kits

BOUNDED MEMORY

Idempotency record

Request key: order-42:create
Stored fingerprint: 2 × field camera kits
Retained until: 1,500 ms
Saved response: 201 · receipt #1

This model treats the retention duration as starting at the first successful commit; replays do not extend it. Real APIs differ in key scope, payload comparison, response storage, and expiry policy.

Preparing the interactive experiment…

Skill practicedReason about retries after uncertain commits and expiry

Connection to my workMy public Agent Activity Ledger contribution rejects conflicting event retries; this synthetic order model adds a lost reply and expiry scenario.

Understand the result

A synthetic order request may commit even though its response is lost. Follow matching retries, a changed body that reuses the same key, and a retry that arrives after the saved record expires. This extends the event-ingestion idempotency pattern in my Agent Activity Ledger contribution into a separate order example; it does not reproduce that repository’s event schema, storage, transaction boundaries, or retention policy, nor does it imply a production order or payment path.

Controls

Reply gets lost: Delivers the same request three times after the first successful commit loses its reply.
Same key, new payload: Reuses the request key with a different order body while the original ledger entry is retained.
Retry after expiry: Retries the same request at 2,200 ms; compare that delay with the configured retention window.
Use an idempotency ledger: Stores the first request fingerprint and successful response, then replays or rejects later uses of that key while retained.
Ledger retention: Sets how many milliseconds the first successful result stays available. Replays do not extend the window in this model.
Reset experiment: Returns to the lost-reply scenario with its starting retention window and the ledger enabled.

What to watch for

With the ledger on, the first delivery creates a receipt. The next two retries replay it, so only one business effect is recorded.
In Same key, new payload, the retained fingerprint turns the second body into a conflict instead of silently repeating the operation.
In Retry after expiry, move Ledger retention above 2,200 ms to replay the receipt; at or below 2,200 ms the key has expired and the effect runs again.
Turn the ledger off and compare deliveries with effects. They can diverge sharply when callers retry after an unknown outcome.

Why it happens

Networks can lose a response after a server has committed the operation, so a caller cannot infer the commit outcome from a timeout alone. A ledger can associate a scoped key with a request fingerprint and saved response. Retention, key scope, concurrency, and the transaction boundary between the ledger and business effect determine what a real system can guarantee; this small model holds those choices deliberately fixed.

How this idea relates to the linked work

My Agent Activity Ledger contribution added idempotency to event ingestion: matching key-and-payload retries are deduplicated, while reusing a key with changed content returns HTTP 409. This separate synthetic order model extends that pattern with a saved response and expiry; it does not reproduce the repository’s event schema, storage, transaction boundaries, or retention policy.

See the broader engineering brief