4

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.

Improve this question
7
  • 1
    There's probably not one solution that always works. Can you tell us more about your system? How often do users send requests for emails? How are you sending emails? – Thomas Owens♦ Nov 16 '15 at 20:16
  • 1
    "The certainty the mail was sent and received is more important than the speed." – gnat Nov 16 '15 at 20:19
  • I have added more information in the question @ThomasOwens. – GiamPy Nov 16 '15 at 20:19
  • 1
    Can you elaborate more on this queueing? What do you mean by "awaits until a response from Mandrill is received"? Are you asking if you should send emails individually or in bulk? Or something else? – Thomas Owens♦ Nov 16 '15 at 20:23
  • 2
    I think that this may be answerable, but I think it may require exposure to Mandrill (or perhaps a similar service), which is something that I don't have. I do think this is a good question in its current state, though. Hopefully you'll get the help that you need. – Thomas Owens♦ Nov 16 '15 at 20:55
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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.