- Developer Hub
- SparkPost API
- Free Tools for Email Teams and Developers
- Slack Channel
- User Guides & Migrations
- Submit a Ticket
- SparkPost Academy
- Email Deliverability Resources
- Email Explained
- White Papers & Guides
- Webinars & Videos
- SparkPost vs. SendGrid
- Customers Stories
- Contact Us
I really enjoy the AWS video series “This is My Architecture.” It’s pretty cool to get a window into how different teams approach architectural challenges building and scaling cloud apps and services. So I was happy to participate in an interview for the series when I was out in Las Vegas for AWS re:Invent a few months ago.
In this short interview by AWS’s Toby Knight, Manager – Solutions Architecture, I discuss some of the unique challenges we face at SparkPost in designing a scalable system that reliably handles large volumes of outbound mail for our customers. In this video, I explain how we decoupled our MTA tiers from the external IP addresses used for email delivery through the use of an SMTP Proxy tier.
Here’s some background: Customers inject their email into SparkPost using SMTP or a REST API. We use Elastic Load Balancers (ELB) in front of our SMTP and REST APIs to load balance incoming traffic to the various MTA tiers. These MTA tiers run on AWS EC2 instances.
A big challenge with this is how to ensure that a customer’s email goes out the proper sending IP. As most large-scale email senders know, the sending IP has specific customer reputation associated with it, so you can’t just send it out whatever IPs are attached to the specific MTA processing a given email. To solve this problem, we use a separate SMTP Proxy tier also running on EC2 where we attach the Elastic IPs (EIP) used for sending and which actually connects to the outside world. This allows us to easily decouple the EIP used to send the email from the MTA used to process the email. While the MTAs are compute heavy and handle the necessary store-and-forward logic, the SMTP Proxy tier is a stateless network proxy. We don’t need that many of these proxy nodes, though there is a limit to the number of EIPs allowed per instance type.
Also, as shown on the blackboard, the MTAs emit a tremendous amount of event data to an AWS SQS (Simple Queue Service) queue, which is rapidly processed and used within our various analytics services and APIs such as webhooks, metrics API, and message events API.
You can learn more about our approach and the architectural challenges with delivering email at this scale in the cloud, as well as some of the AWS technologies we’ve been able to leverage.
It was great to meet the “This is Your Architecture” team and a fun experience to participate in this video! Looking forward to seeing them again this year at re:Invent.
CTO & FounderSparkPost © 2018 All Rights Reserved