Use a durable delivery-claim ledger keyed by the logical password-reset challenge, channel, and message purpose; commit that claim before dispatch, reuse the same idempotency key on every retry, and record an ambiguous outcome as unknown rather than pretending the notification was sent exactly once. For a gaming account reset with a short expiry, compliance evidence is the deciding constraint: the system must explain why an email or SMS was attempted, which logical message it represented, and what the transport acknowledged without storing the reset secret itself.
Exactly-once is the wrong external promise. A worker can crash after a transport accepts a message but before the acknowledgement reaches the backend. No local flag can distinguish that case from a request the transport never accepted. The defensible goal is narrower: one durable intent, one stable deduplication identity, bounded retry behavior, and an audit trail that preserves uncertainty.
It sounds fussy. It isn't.
Minimize reset data before deduplicating it
The ledger needs an opaque challenge identity, not the secret that authorizes the password change. That privacy boundary comes first; deduplication cannot justify copying credentials into a longer-lived evidence store.
