Is it always the best way to go to queue emails instead of sending them real-time? [duplicate]

Question

This question already has an answer here:

• What is the benefit of offloading email to a transactional mail service? 1 answer

If you had to decide between queueing emails and sending them real-time, is it always the best way to go putting them in a queue and sending them one by one instead of instantly as soon as a user sends the request?

Emails are sent using an external service that is Mandrill. Evertime someone submits a specific form in our website, a notification email of the successful operation is sent. These "requests" are then handled in the back office by another team and then another email is sent to the original requester.

We are also going to need to build a marketing email system within the application so that's that.

What I meant by queueing emails (since we are using Mandrill) is queueing the API call to the service instead of sending it non-asynchronously. Since sending the email is not instantaneous, the client awaits until a response from Mandrill is received, instead of handling it with a queue system (like beanstalkd).

Here's a code sample of what I mean.

public function example($id)
{
    [...]

    $Mandrill = \App::make('mandrill');

    $message = $Mandrill->prepareEmail(
        [...]
    );

    $Mandrill->messages->send($message, false, null, null);
}

We immediatly send the API request and since the response is not immediate, the request stalls because it is waiting for the API response, that is what I mean by real-time (not sure if that's the correct term maybe?).

What I have shown you above is part of my current application's code base. What I am asking is if it's worth refactoring the code so that the API requests are sent over a queue of items and have a queue manager (with beanstalkd for example) handle them one by one on a separate request behind the scenes.

Answer 1

Since emails are not realtime pr guaranteed delivery there is no obvious benefit to sending them in a blocking manner. However, it isn't that simple in practice and blocking can have merit.

Go with asynchronous/queueing sending if blocking harms upstream processes.

Go with synchronous/blocking sending if the upstream process needs to know that the attempt to send failed in a trivial way (SMTP unavailable, SMTP authentication failed, etc.).

I would go with async as my default approach and either log failures or have a separate queue for send status that the upstream process or downstream monitoring processes can subscribe to and act on.