8
votes

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.

2

2 Answers

5
votes

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.

2
votes

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.