Three clocks, one request: why reset emails duplicate under a 429

A dev.to post on password-reset email retries makes a diagnosis worth borrowing: when an email API answers 429, the bug is rarely the backoff formula, it is that the web request owned delivery in the first place ^[1]. The prescribed shape is one durable delivery job per reset request, a valid Retry-After honored by the worker, and a user-facing cooldown kept independent of the worker's retry schedule ^[1].

The failure starts with the convenient implementation: send from the reset endpoint, and if it fails, let the user click again ^[2]. According to the author, that couples three clocks with three different jobs into a single request: the security lifetime of the reset token, the user-facing cooldown, and the provider-facing retry delay ^[3]. Under throttling those clocks turn one click into duplicate messages, stale links, or a button that reports success while no durable work exists anywhere ^[4].

The counter-pattern is to return from the public endpoint after recording intent, not after waiting on the provider ^[5]. Create the random token, store only the verifier or digest needed to validate it, and enqueue a message that points at the current reset record, in one database transaction where that is possible ^[6]. If queue publication is separate, commit an outbox row beside the reset record so a crashed process cannot leave valid security state with no delivery job ^[7]. The public reply stays neutral about whether the address is registered, and a provider's 429 never surfaces in the browser as an account-dependent response ^[8].

Identity discipline is the part teams skip. The post names four identifiers: a request ID for one browser action, a reset ID for the current security operation, a delivery ID that is the idempotency boundary for one logical email, and the provider message ID for correlating later delivery events ^[9]. The token string is neither an idempotency key nor a log field, because it is a credential, and the reset URL should be redacted from structured logs ^[10].

On the worker side, a valid Retry-After schedules the existing delivery for that time; when it is absent or unusable, capped exponential backoff with jitter applies ^[11]. The Python sketch caps at 15 * 60 seconds ^[12], which is 900 seconds or 15 minutes ^[13], with the backoff base set to min(2 ** attempts, 15 * 60) and jitter drawn uniformly between half the base and the base ^[14] - so jitter only ever pulls a retry earlier, never later ^[15]. Note also that the same clamp applies to the provider's own number: a Retry-After of an hour would be attempted again after 15 minutes, earlier than asked ^[16]. What must not happen is sleeping inside a web process, holding a transaction open, or minting a fresh reset token because transport is throttled ^[17]. A worker lease can expire; a durable next_attempt_at cannot ^[18]. The unit of work is a state transition guarded by a lease: one worker claims a due delivery, attempts it, and records accepted, retry_wait, or a terminal result, and another worker can reclaim an expired lease without creating a second logical message ^[19].

The repeat-request endpoint runs on the cooldown clock, not the provider's. During cooldown it records no new delivery and returns the same neutral response; after cooldown it may rotate the reset operation and enqueue exactly one replacement ^[20]. Whether the older link survives is a decision to make explicitly: invalidating the previous reset is the cleanest rule, provided the email copy warns that only the newest link works ^[21].

None of this is specific to passwords. The author applies the same rule to an edtech receipt after payment settles: commit the business event, create one durable notification job, and let delivery absorb provider backpressure without replaying the payment or inventing a second receipt ^[22].