Email infrastructure · Build
One sending service for every email your product sends
Each email goes from a template through a queue to one sending service, which records it. A US marketplace sent renewal and payment emails from 55 templates.
EngagementHourly · remote
Hours9–18 CET · 4 h overlap
StackNode.js · AWS Lambda · SQS
Proof3 case studies
The service in 4 parts
01 · Who it’s for
A product that sends renewal notices, reminders and payment emails, and a team that needs to know what went out, to whom and why.
02 · What we’ve built
- Renewals, payment notices and re-engagement on a US marketplace went out from 55 email templates through a single sending service.Case study 07 →
- Every message started the same way: data from the database and a template from object storage, then a record of the send and a message on the queue. On staging the sending service delivered everything to one test address. A test run had no way to reach a customer.Case study 07 →
- We moved a live marketplace’s mail onto a queue in the first two months of stabilizing it, before any code was rewritten.Case study 04 →
- For recurring payments, the customer gets one email when a charge succeeds, another when it fails and a third ahead of the next charge.Case study 18 →
03 · How we work
01 · ONE ROUTE OUTJobs don’t send mail themselves. They put a message on the queue, and one service picks it up and sends it.
02 · THE RIGHT CHANNELFor some messages the product itself is the better channel. On the marketplace, a reminder about an unfinished draft listing appeared in the app instead of arriving by email.
04 · Stack
Node.jsAWS LambdaSQSS3HandlebarsMySQL
Proof
Where we’ve done this before
Case study 07 · Marketplace6 jobsRenewals, payment notices and re-engagement on a US marketplace went out from 55 email templates through a single sending service.Read the case study →Case study 04 · MarketplaceZero outagesWe moved a live marketplace’s mail onto a queue in the first two months of stabilizing it, before any code was rewritten.Read the case study →Case study 18 · Business systems4 marketsFor recurring payments, the customer gets one email when a charge succeeds, another when it fails and a third ahead of the next charge.Read the case study →
FAQ
Questions about this service
Because some rules have to cover every message, such as redirecting mail outside production, recording what was sent or changing how mail goes out. With one service, each rule is written once. When every job sends on its own, every job has to remember every rule.
In object storage. Each job reads the template it needs, so a template is changed in one place.
Yes. Every job writes a record of what it sent. On the marketplace the jobs logged nothing but failures, and for email tied to revenue that wasn’t enough: you also need a report of what was sent.
Next step
Describe the problem and we’ll come back with three options.
The first call takes 30 minutes, and you’re under no obligation.