This is a follow up to https://medium.com/schibsted-engineering/building-a-serverle... where a serverless email delivery service was built. SQS has new features since and optmization using 0x flamegraph tool

Agree, not intentionally misleading though. Just a lack of a better word I guess. Original title was "Building a serverless emailing service".

About testing: It's not that different from any other runtime. I admit, I put a lot of code into the same file in the examples as it was easier displaying the code that way. I tend to keep the handler of the lambda very lightweight and then test the functions that the handler calls. That way it's just unit testing and mocking away dependencies. The functions are pretty small so naive dependency injection works fine. AWS docs covers testing of Lambdas a bit here: https://docs.aws.amazon.com/whitepapers/latest/serverless-ar...

You're right! Bounces and complaints needs to be handled properly and the design does not reflect that.

SES uses account-level suppression lists, to avoid sending emails to addresses that has complaints, hard bounced or soft bounced a number of times. It does not automatically handle bounces sent over email, and I've not seen a provider out there doing that but I could be missing it.

We do manually monitor those however, by having the FROM address directed at an inbox that we monitor. Out of the 4M emails we send per month, we only get one bounce email back. And that's not really a bounce but a "please confirm you are real" bounce.

This could probably be automated with SES too, by parsing incoming emails and adding addresses to bounce list. For that 1 email per month we decided not to add that complexity.

Note: This setup is used for transactional emails, where users opt in via account creation and the first email sent is a verification email, to check that the address is real and that the user owns it.

Thanks...it does appear to handle the live SMTP bounces better than I thought, at least for hard, synchronous bounces that happen at SMTP delivery time: https://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-e...

However, my experience was that you also had to do something with soft bounces. For example, if someone's mailbox is perpetually full, re-sending to it over and over still can still eventually hurt your sending reputation.

Yeah, SES puts those soft bounces on suppression list too after a number of failed attempts. That is actually an issue we've struggled with. A large number of users using a mail service with just 10MB of storage. Those mailboxes were always full and we got soft bounced over and over until SES put them on suppression list. User contacted support and got told to clean out the inbox to make room but emails could still not be delivered until we had manually remove the address from the suppression list.