Retries and ambiguous transaction outcomes

A confirmed serialization abort means the transaction did not commit under the database’s contract. Retrying normally requires a fresh transaction, rereading inputs, and repeating decision logic. A lost connection during commit can instead leave the outcome unknown to the client. A timeout describes the caller’s waiting boundary, not the database’s final state. Retrying an increment or quota transfer under a new identity can duplicate an operation that already committed. Keep these categories distinct in application errors and operational metrics.

Use a stable logical operation key when the service supports idempotent requests. Record the key, relevant request parameters or their validated identity, and the resulting effect or response in one protected transaction. A duplicate key with incompatible parameters should be rejected rather than silently treated as the original request. Define retention duration and scope: an expired key record may no longer prevent replay, and a key unique only within one tenant must include that tenant in its identity. These are parts of the API’s semantic contract.

Two retries can both read that a key is absent and then each apply the effect unless checking and recording are coordinated. Use a unique constraint, transactional claim, or equivalent proved mechanism together with the effect. A deduplication entry written before an effect and an entry written after an effect each create a crash window if they are not atomically connected or recoverably reconciled. Also ensure the stored result corresponds to the same business intent, including amount, destination, and authorization context where relevant.

Automatic database retries cannot roll back an email, payment call, or message already delivered outside the transaction. Place external delivery behind an appropriate durable handoff or use an external idempotency contract that the workflow can reconcile. When a commit result is ambiguous, querying the stable operation record may establish the outcome if the read is authoritative under the system’s consistency rules. A stale replica reporting no record is not necessarily proof that the operation never committed. Preserve unresolved intent until the documented recovery path can answer.

Use a finite attempt budget or overall deadline, backoff, and jitter appropriate to the caller’s contract. Treat exhausted retries as a visible outcome rather than hiding them behind a successful-only latency graph. Observe attempted transactions per accepted logical operation, serialization-abort rate, ambiguous outcomes, and deduplication hits. A rising retry ratio can consume database capacity and increase conflicts further. Backoff can reduce that feedback, but it does not repair missing atomic deduplication or a transaction whose decision logic is never refreshed.

The probability lab uses a different fixed-count model. Reset, set success probability to 0.1 and trials to 5, interpret a marked outcome as an assumed abort, predict the probability of at least one mark, then Step. The exact binomial bars describe five independent attempts with one fixed probability. They are not the geometric distribution of attempts until success, nor a contention simulator. Explain why actual retry feedback can violate independence before using any simple probability model for capacity planning.