Reasoning about a mutation whose response can be lost after commit. The likely minimum is a client-scoped idempotency key, a durable uniqueness constraint, request identity validation, and storage of the terminal response in the same transaction as the business effect. The key questions are how to handle concurrent attempts, failures before and after commit, and side effects outside the database.
The minimal design uses a client-generated idempotency key scoped to the caller or operation, a canonical request fingerprint, and a durable record protected by a unique constraint. In one database transaction, insert the key, apply the business mutation, store the terminal response, and commit. A retry with the same key and fingerprint returns the stored response; a different fingerprint is rejected. The uniqueness constraint serializes concurrent attempts. A crash before commit rolls everything back, while a lost response after commit is recovered by replay. For effects outside that database, add a transactional outbox and make delivery idempotent because a database transaction alone cannot guarantee exactly-once remote execution.
For a canonicalization rollout, persist both request schema version and fingerprint algorithm version beside every fingerprint. The record already owning the idempotency key is authoritative. On retry, convert the incoming request into that record's historical semantic domain using only explicit effect-preserving compatibility rules, then compute exactly the historical fingerprint. Never accept merely because any supported fingerprint version matches. A new field may be dropped only if it is non-semantic or provably equal to the historical default; otherwise reject key reuse. The winner of concurrent old and new attempts fixes the versions and intent under the unchanged unique key. After identity matches, replay the immutable stored result, rendering it through a versioned response adapter when the caller requires another compatible response schema; never execute the mutation again. Deploy all old-version readers and adapters before enabling new-version writes, and retain them until old records expire.