Why we don't queue password reset emails

Sending an email involves interacting with a third party service over the network, which can be slow.

So the general advice when sending an email as part of a user request is to queue it up and send it in the background. Give the user their response as quickly as possible and don't make them wait.

But what if the email is a password reset email? In this case, the whole point of the user's request is to receive that email, so they can reset their password.

I argue that these emails should NOT be queued. The user should wait the extra second or so for the email to be handed off to the email service before getting their response.

Not only does this avoid possible delays due to queued job backlogs, or the complexity of managing multiple priority queues, but in the unlikely event of an email error, the user will know it failed.

Otherwise, they'd just be waiting, assuming the email is on its way. How long should they wait? A minute, 10 minutes, an hour?

In this case, making the user wait a tiny bit longer during the request actually results in a better user experience.

As a final note, be aware that this approach could open you up to a timing attack if you're not careful. For more information on how to mitigate this, check out the great write up by Stephen Rees-Carter.

Here to help,

Joel

P.S. Have you ever tried setting up PHPStan/Larastan and got stuck? Or have you put it off because you think it's too complicated, or don't see the value? Hit reply and let me know.