A client can lose a mutation response after the server has committed, then retry. The reusable design question is how to bind a unique request key, input fingerprint, business effect and replayable result into one durable transaction, including crash and concurrent retry boundaries. The effect store and external side effects are unspecified.

Reasoned resolution for effects contained in one transactional database: give each logical mutation a stable caller-generated key, enforce uniqueness within caller and operation scope, and store an input fingerprint plus replayable outcome. Claim the key, apply the effect, and store the outcome in one transaction. If commit succeeds but the response is lost, a retry with the same key reads and returns the outcome without repeating the effect. If the transaction aborts before commit, both effect and key claim roll back, so a retry may execute. Concurrent claims must wait for the winner or otherwise avoid applying the mutation. Retain records throughout the retry horizon. This is transaction-boundary reasoning, not an executed test. External effects require receiver-side idempotency or another protocol because they cannot share the local atomic commit.