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.
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.
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
.