bcmiller/gist:1996480

## gistfile1.txt

The way I'd see it working is:

Use notifications api to define templates etc for your email

When you reach the point in your app where you send the email, add the email send request to the notifications queue.

Write a drush command which processes your queue

Implement drush daemon which monitors the queue at a configurable interval (1second+) and if it finds any items on it, sends them

You could go to one further level of abstraction and bypass notifications altogether, your user request that triggers the email send simply adds to a queue (use the queue api) containing the data of the user, the email template type and custom data (ie from a form) and then use drupal_mail to send the mail directly from the daemon monitored queue.

The benefit is that whilst volume are low to average your queue will process in as near to real time as makes no odds, but if you get a spike in load you're just adding to your queue and not impacting user experience as the mail server begins to creak.

	The way I'd see it working is:

	Use notifications api to define templates etc for your email

	When you reach the point in your app where you send the email, add the email send request to the notifications queue.

	Write a drush command which processes your queue

	Implement drush daemon which monitors the queue at a configurable interval (1second+) and if it finds any items on it, sends them

	You could go to one further level of abstraction and bypass notifications altogether, your user request that triggers the email send simply adds to a queue (use the queue api) containing the data of the user, the email template type and custom data (ie from a form) and then use drupal_mail to send the mail directly from the daemon monitored queue.

	The benefit is that whilst volume are low to average your queue will process in as near to real time as makes no odds, but if you get a spike in load you're just adding to your queue and not impacting user experience as the mail server begins to creak.