Send emails using SQS or SNS

Question

I have a web application that should send emails to admin users when something happens in the application. For instance, a new user is registered.

I would like to avoid having the logic of building/sending the emails inside of the application. I would rather prefer that the application publishes a message in a queue, and then, there is another system listening and reacting properly to send the emails.

The flow would be something like that.

• The application publishes a message in a queue (SQS or SNS??)
• A lambda function is trigger. Lambda reads the message and calls SES.
• SES sends the email

I'm not sure if that is the best way of doing this. I have read that there is a gap between SQS and Lambda. Would it be better with SNS?

What would be the proper flow?

App -> SQS -> Lambda -> SES

or

App -> SNS -> Lambda -> SES

Maybe something else?

Please, take into consideration that the idea is always to abstract the web application from all that logic. The web application would only publish a message somewhere. Then the magic happens in the background.

Solution 1

Based on your description, I'd propose the following architecture:

App -> SQS -> Lambda -> SES

I'd use SQS to execute the Lambda function from the app or use Cron job worker to run it periodically as a worker on the queue.

This architecture decouples the App from the mailing service, provides asynchronous invocation and queueing. If you need to send larger payloads, use S3 to store these objects and just pass the keys in SQS messages to your Lambda.

Solution 2

Take SNS out of the equation for email, as you need to be a subscriber to a topic to receive notifications. It's really for AWS related event notification.

With SQS, you have to deal with Limits Related to Messages. Default max message size is 256kb unless you use a special SDK then it is 2GB.

Consider a 3rd option. App -> DB -> Lambda -> SES

A mail queue in the DB is an easy table structure, and you have Lambda scan it on a scheduled or event-driven basis and process mails via SES. And this way there is no SQS message limit.

Comments

[osotorrio]

I am not worry about the message limit (still good to know). Because the app will publish as a message an id or token representing the user. The content of the email would be in a template in somewhere else. Do you stick to your recommendation after knowing this?. Thanks

[jzonthemtn]

I wouldn't so quickly omit SNS. It is made for sending all notifications, not just AWS-related notifications. Events can go to an SQS queue, from where each is consumed and trigger an SNS notification. By using SNS instead of SES directly you have more control over the delivery of the notifications. For example, if you have notification rules (based on time of day or subject) that logic can pick the SNS topic, and each SNS topic has the appropriate email addresses subscribed.

[Mark B]

The question is about using SNS to trigger a Lambda function, not to send emails directly. Your dismissal of SNS is unwarranted in this scenario. In fact I think SNS->Lambda->SES is the most elegant and fool-proof solution to the question being asked, and the only solution being proposed that doesn't rely on Lambda running on a schedule.

[Charlie Schliesser]

As of Jun 2018 you can run Lambda from an SQS event, so you don't need to use cron or SNS to invoke it.