Email verification is often implemented as a small feature: create a token, send a message, and activate the account when the link is opened. That design works until the database commit succeeds but the email worker fails, or a client retries the request while the first message is still in flight.

The safer mental model is a transaction with an asynchronous side effect. The account state, verification attempt, and delivery request should be recorded together. A worker can then deliver the message at its own pace, while the API remains the source of truth.

Why a verification request is a transaction

A verification request changes more than one thing. It may create an account, issue a token, and enqueue an email.…