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.