Email might be one of the most often overlooked pieces of any web application. Usually the biggest discussion around it in a project begins and ends with \u201cand we\u2019ll send them an email when this happens\u2026\u201d.<\/p>\n
A little thought and some minor adjustments can help us avoid some problems that will grow as your project does. Let\u2019s talk about email as a microservice.<\/p>\n
Most web frameworks include some semi-standard way of sending an email, ranging from the simple Sending via SMTP tends to create a noticeable performance hit to page response times, especially if you\u2019re sending more than one in a request. That will eventually lead to backgrounding your email deliveries to some type of job queue. A lot of frameworks have taken steps to make this process easier with some variation of a Eventually, that\u2019s going to lead to wanting to verify that emails were delivered. You\u2019ll have something monitoring your job queue or potentially tracking your deliveries, either via webhook integrations with an email provider or creating your own 1-pixel tracking image.<\/p>\n As you place more importance on ensuring your emails are delivered, you\u2019ll either create a simple buffer to allow you to tolerate a hypothetical outage, track recently sent emails and delivery confirmations, and debug delivery concerns for your users. You may one day wish to have statistics for different types of email that you send or even for specific users. You\u2019ll need to account for how to handle email bounces and spam reports, not just for future deliveries but for your application itself. As your volume increases, you\u2019ll have to ensure you\u2019re keeping SPF up to date, DKIM periodically rotated, and monitor your DMARC reports to maximize deliverability and combat phishing.<\/p>\n If you\u2019re delivering based on user-generated content, you\u2019re going to need some spam checks with the likes of Spam Assassin<\/a>. If you don\u2019t have spam checks, you\u2019re going to want to monitor email blacklists like Spamhaus<\/a> to see when you become an offender or able to respond to major email responders suddenly refusing all of your mail. That will probably lead to a change in your sending domain name at some point too, as you separate your critical messages from the user-generated ones.<\/p>\n Through all of this process, you\u2019ve created dozens of different types of email within your application: different templates, different triggers, and different levels of importance.<\/p>\n You\u2019re going to start separating different types of email into different levels of delivery priority, because now your emails are probably intermingled with your application job queue, and your users are filling out support tickets because they didn\u2019t get a receipt as fast as they expected.<\/p>\n If you send out a lot of email at a time, then there\u2019s the potential for all of those inbound webhooks and tracking images to hit your web server at the same time. This can cause a traffic spike and probably a database spike from tracking that could have a performance impact for the users on your site.<\/p>\n As your application itself grows, it\u2019s inevitably going to be split into parts as well. Different parts of that application will probably need to send emails too. At that point, you\u2019ll have the option of either configuring each individual part to deal with these things itself, scattering templates everywhere\u2026 or centrally creating an email API in your monolith, cluttering your application\u2019s API requests and job queue with lots and lots of emails.<\/p>\n These are the factors we\u2019re looking at before we even consider things like testing, configuration settings, review from non-technical folks, etc.<\/p>\n \u201cProvider X\u201d probably does handle a lot of the things I just described. It probably handles them very well. Many of the email-as-a-service platforms provide excellent tooling around a lot of what I described, immediately when you sign up. I highly recommend investigating these services. Just remember that those services might not always be there. They might have outages, infrastructure problems, or delays. Worst case, those services might simply be discontinued.<\/p>\n When that happens, what do you do? Have you invested a lot of time in building around one provider? If that provider is managing your bounce\/spam list, will you accidentally end up spamming users by pointing to a different service? Are you able to export that data from your provider?<\/p>\n These are all questions that need to be answered. One of the keys to a successful business is redundancy: having a backup plan; having a failover; not being tied to a third party for core parts of your business. And if you\u2019re on the web, odds are high that email is a core part of your business. It\u2019s definitely a balancing act, but if the redundancy is easy and relatively inexpensive to solve, it\u2019s probably a good idea.<\/p>\n You don\u2019t have to build everything I just described to separate your email into a service. That\u2019s what premature optimization looks like, and in the beginning, you\u2019re just trying to send some email.<\/p>\n Apply the K.I.S.S. (Keep It Simple Stupid) principle here. What exactly do I need from my email service to start with? We need to tell it that we want to send an email and then have that email sent. That\u2019s it. Don\u2019t overthink it and don\u2019t set the barrier to entry too high.<\/p>\n The point of separating your application email early is that the complexity of your email system is going to grow as your application grows. It\u2019s never going to be a big \u201cnow we\u2019re doing email\u201d project, and that is exactly where the problems come from.<\/p>\n The slow growth of your email infrastructure within your application leads to entanglement of your email infrastructure within your application long term: clogging your queues, creating web tracking traffic, increasing load on your database from analytics, taking up space in your database, and overlapping embedded assets. These things will often come in bursts that don\u2019t reflect the real load challenges for your user-facing system.<\/p>\n Think of separating email early like planting a seed in its own bed. It can still grow, but you don\u2019t have to worry about the roots getting tangled.<\/p>\n A service? Doesn\u2019t that mean I\u2019m going to have to create a REST API and manage all the endpoints and version it and handle authentication and run a web server and manage a client library just for that!?!<\/p>\n Glad you asked because no, no it doesn\u2019t. People often hear \u201cservice\u201d and think \u201cfull API,\u201d which is overkill for something that isn\u2019t public.<\/p>\n So let\u2019s think about this. Say you\u2019re running a Rails application; how would you send email? In the background with something like Resque<\/a> or Sidekiq<\/a>? Probably.<\/p>\n So do exactly the same thing. Create a separate application with a worker on its own queue and give the other parts of your application the connection information so that they can drop jobs into that queue. That\u2019s the whole API.<\/p>\n Use any format you like, but that Resque\/Sidekiq structure is simple enough and popular enough that many other languages support sending and receiving jobs using the same structure. It\u2019s almost an unofficial standard at this point.<\/p>\n Now you don\u2019t even need a web server. All you need is access to a connection and the ability to write a JSON structure.<\/p>\n Your email service is nothing more than a single background worker with its own database. All of your templates, SMTP connection, delivery rules, different types of email, tracking, and assets will grow in their own space. But remember that you probably don\u2019t need all that to start out, so we avoid overkill and keep the barrier to good architecture at the expense of man hours and complexity to a minimum.<\/p>\n As a bonus, deploying updates to your email service won\u2019t affect the other parts of your application that are trying to send emails, since those are going directly to the queue anyway. You\u2019re not redeploying the queue, just the worker.<\/p>\n Over the long term, email can and will get more complicated. You\u2019ll eventually have non-technical people that may want to review the emails and make suggestions, which usually leads to coding up a \u201cdefault\u201d way to send each type of email OR you can create some type of web interface to review the template structure.<\/p>\n We talked about redundancy earlier, so you may want to preconfigure multiple delivery providers and define your own rules for who sends what and when. Blacklist management will become a big deal; if you\u2019re using more than one provider, you\u2019ll create problems for yourself if somebody reports you for spam on one and then you send again to another. If you have support staff, you probably aren\u2019t going to want developers to get a call every time somebody has a question about their email, so some type of web interface for support can help.<\/p>\n This growth can seem fairly daunting. Luckily there are some options that can give you a lot of what we\u2019re talking about without forcing you to custom build it all while preparing for potential transition. There are a lot of popular email-as-a-service providers out there, like Sendgrid<\/a>, Postmark<\/a>, Mailgun<\/a>, and SparkPost<\/a>. Sendgrid and SparkPost both have APIs to let you export and load a blacklist. So those two services in particular are optimal for redundancy if you need to switch from one to the other in case of outage, service problem, or some other reason.<\/p>\n Some providers offer template handling options, delivery tracking, and webhooks, but coding up solutions for each of them would probably be overkill. Likewise, they each provide mechanisms for tracking deliveries to see what happened if there\u2019s a customer inquiry, though not including the ability to resend. For future customer support, you\u2019re probably not going to want to ask support staff to check each one and then build an additional system to let them resend.<\/p>\n For this case, there\u2019s a handy service called Sendwithus<\/a> that can bring it all together. Sendwithus lets you configure multiple email providers from a single interface, create templates on their system, and track delivery history on a per-customer basis. From a customer screen, you can see every email sent to a user with a simple button click to resend. Sending a message is as simple as making a REST call that includes your account key, the identifier for your template, and the payload for that template in simple JSON. Designers and marketing folks will have the ability to review and update all of your email templates centrally without ever needing to change code. It won\u2019t manage your blacklists for you, but if you\u2019re using Sendgrid and SparkPost, you\u2019ll be able to code up your email service to sync it back up.<\/p>\n Initially that setup is still probably overkill. All we really need to get started is our email service and an SMTP server. But knowing what\u2019s out there helps us create ideas for what a future plan might look like as we grow and change. Growing and changing gets a lot easier when our email was separate from the start.<\/p>\nmail()<\/code> command to wrapping an entire templating system to abstract the pieces. These days, your next step is usually connecting to one of the popular mail delivery providers via SMTP to make sure it\u2019s delivered.<\/p>\ndeliver_later<\/code> or send_later<\/code>, which is very beneficial.<\/p>\nBut wait! I use Provider X!<\/h3>\n
Separate Early and Simply<\/h2>\n
Anatomy of a Simple Email Service<\/h2>\n
The Long View of Email as a Microservice<\/h2>\n