on
How Not To Send Transactional Emails
Disclaimer: this is the anti-aws guide to sending emails
The problem
You have a system and you need to send emails to your customers which happen upon certain events, for example a new user signs up and you send him a welcome email. At the same time you are using aws and to ensure the least problems you decided to use as much as much possible of what Jeff is selling. Based on that you decided to use SES (simple email service) to send your emails (far from simple if you ask me, but that’s how they market it).
The AWS Solution
Lets take the following scenario: you want to send an OTP to your customers so they can login to your platform, that by extension means that the user needs to receive the email otherwise they can not use your service. That said if the email was not received you either need to re-send it or it should be marked as not sent and then inform the customer. That sounds reasonable right? At least to me!
How will you implement this on aws with ses or better yet what does aws suggests you need?
- SES
- SNS
- Lambdas
So you need your application that will send the email and then set an sns topic to handle bounces, which then calls a lambda.
Lets visualize this
So you will need to pay for SES, SNS and AWS lambda. Up to a certain load which is relatively unclear, you can pay almost nothing for it. However, if things start to increase you pay a lot. Then you will to pay developer and devops to maintain it, which is even greater cost money wise and mentally.
To say the least this is complicated, cumbersome and hard to test like everything lambda related.
What can you do instead?
You need to do 2 things, firstly ditch the lambdas they are useless and they only promise low prices which deminished as soon as you load increases. Secondly, don’t use SES, it’s hard to setup, instead use another SaaS service that specializes in email delivery.
- Postmark
- Sendgrid
- Mailjet
- Brevo
The list of providers is big and you can google the rest.
How do they work someone would wonder? Well you call an api with the provided details, then you have webhooks that will provide you with a simple notification on the state of the email.
Benefits
- Simple architecture - you merely integrate with an API (most offer SDKs) and then you ensure they inform you back using a webhook, where you receive updates on the state of the email.
- Easy to build and maintain - you just need an application serving HTTP requests (like 90% of the applications theses days).
- Less infrastructure - you don’t have to manage Lambdas, SNS and SES and yes they are considered infrastructure and they require management.
Comparing the cost of these solutions is not possible without knowing the load of the systems. It’s well known fact that Lambdas are very cheap when they are not used, however cost increases together with the load.
Conclusion
Don’t use every AWS product they offer, just use the right and simplest tool of all. Ensure that you are not tied together with one provider. Don’t fall for the marketing of cloud providers.