Idempotency is a ledger correctness problem

For financial state, idempotency is not just an API convenience. It is part of how the ledger proves what happened.

Retries are not exceptional in distributed systems. They are a normal part of client libraries, gateways, job workers, queue consumers, and operational recovery.

In ordinary systems, a duplicate request might be annoying. In value exchange systems, a duplicate request can become a double debit, a missing credit, or a support case that is hard to explain.

The retry is not the problem

The problem is ambiguity. When a client times out, it may not know whether the operation failed before validation, failed after validation, committed successfully, or committed but lost the response on the way back.

A ledger system should not ask application code to guess. A stable operation identity should let the system return the same durable outcome for the same logical operation.

Idempotency needs durable state

Idempotency cannot be only an in-memory cache. It also cannot be only a short-lived gateway feature if the financial result must remain explainable later.

For ledger operations, the duplicate decision should be tied to persisted operation identity and persisted result shape. That way a retry can map back to the original committed, pending, rolled-back, or rejected outcome.

Duplicate handling should be deterministic

Two requests with the same operation identity should not race into two different financial realities. The ledger layer needs a deterministic answer to a simple question: has this logical operation already been decided?

If yes, the duplicate should observe the stored result. If no, the operation can proceed through the normal validation and mutation path.

Rejected outcomes matter too

A rejected request is still an outcome. If an insufficient-funds transfer is rejected and the same operation is retried, the system should not accidentally reinterpret it as a new debit after the account is later funded.

This is one reason TulaDB treats rejected transactions as part of the ledger story. Rejection visibility supports duplicate protection, auditability, and customer-support explanation.

What to review in private preview

Private-preview reviewers should test idempotency under realistic conditions: client timeout, duplicate submit, worker restart, reconnect, and replay after recovery.

The useful question is not only whether a duplicate is blocked, but whether the observed result remains stable and explainable.