Idempotency Starts with Business Operation Identity

The hardest part of idempotency is often not the retry. It is deciding when two attempts represent the same business operation.

Sometimes the identity is a request ID or external message ID. Sometimes it is a business key or a state transition that may happen only once. Once that identity is explicit, a transaction and database uniqueness constraint can enforce it, even when two attempts arrive together.

Without identity, "make it idempotent" is not yet a design. The system still does not know what must not happen twice. This matches how Stripe and AWS describe safe retries: repeated attempts need a stable identity so the original side effect is not performed again.