The Boring Stack Behind SMTPfast (And Why Boring Is Reliable)

There is a quiet worry people have about a small, fast email API: if the tool is this simple, is the infrastructure behind it actually serious? Will my email really arrive?

We want to answer that head on, because the answer is the opposite of what the worry assumes. SMTPfast runs on a deliberately small stack, and that smallness is the whole reason it is reliable. Fewer moving parts means fewer things that can break, fewer places a message can get stuck, and a system a human can hold in their head end to end. This is the whole architecture, start to finish.

The whole stack in one paragraph

A Next.js app serves the dashboard, the marketing site, and the API. Postgres is the durable record of every email, event, and account. A Redis-backed queue holds each send. A separate worker process pulls jobs off that queue and hands them to Amazon SES, which does the actual delivery. The database and Redis run as managed services, and the app and worker run as containers under orchestration that keeps healthy copies alive and replaces any that fall over. That is it. No sprawl of a dozen microservices, no bespoke message bus, no service you have to page through to understand what happened to one email.

Small on purpose

Every component you add to a system is a component that can fail, needs monitoring, and has to be reasoned about when something goes wrong at 2am. The industry default is to reach for more: more services, more layers, more infrastructure that looks impressive on a diagram. We reach for less, and we add a moving part only when a real failure mode demands it, never because the architecture looks more grown-up with it.

The payoff is not just simplicity for its own sake. A system you can fully understand is a system you can make reliable. You know exactly where a message is at any moment, exactly what happens when a step fails, and exactly what to check first when something looks off.

What happens when you call the API

The important design decision is what we do the instant your request lands. We do not send the email inline. We write it to Postgres, drop a job on the queue, and return. Your API call is fast and it cannot be blocked by a slow network, an SES rate limit, or a momentary hiccup downstream.

POST /api/v1/emails
      |
      v
 [ Next.js API ] --- validate, persist the email row, enqueue --> return 200 (fast)
      |
      v
 [ Redis queue ] --- durable, 3 retries, exponential backoff
      |
      v
 [ Worker ] --- rate-limited to SES throughput, jobs run concurrently
      |
      v
 [ Amazon SES ] ------> the inbox
      |
      v
 events + webhooks: queued -> sending -> sent / failed / retrying

From there, the worker takes over, and this is where the reliability lives:

• Automatic retries. Every job gets up to three attempts with exponential backoff (1s, then 2s, then 4s) before it is ever marked failed. A transient network blip or a momentary SES throttle heals itself with no action from you.
• Rate limiting that respects SES. The worker sends at SES's throughput rather than firing everything at once, and it runs jobs concurrently. A burst from one sender does not trip provider limits or starve everyone else.
• Isolation between web and worker. They are separate processes. If the worker is restarting during a deploy, your API calls still succeed and the queue holds the work until the worker is back. A send never blocks a request, and a deploy never drops a message.
• A visible trail. Every state change (queued, sending, sent, failed, retrying) is written as an event and pushed to your webhooks. You and we can see exactly what happened to any message.
• Dead letters that page us, not you. When a send exhausts its retries, the job is kept for seven days for inspection and we get an alert immediately. A systemic problem surfaces in minutes, from our monitoring, not from a customer email.

Where the reliability actually comes from

The reason SMTPfast is dependable is not that we bolted on a dozen extra services. It is that we delegated the genuinely hard problems to managed infrastructure and orchestration built to solve them, and kept our own surface area small enough to run well.

• Amazon SES does the delivery. The final hop to the inbox rides on the same infrastructure that moves enormous volume for AWS, with its own redundancy, IP reputation management, and bounce and complaint handling. We did not try to out-engineer email delivery. We build on the layer that already does it at scale.
• Managed Postgres holds the durable record. The database runs as a managed service on DigitalOcean with replication, automated backups, and failover to a standby, so no single database node is a single point of failure and every email and event survives a restart.
• Managed Redis backs the queue. The queue's store is managed and maintained the same way, so sends do not live in the memory of a box we are hoping stays up.
• The app and worker self-heal. Both run as multiple container replicas under orchestration. Health checks catch an unhealthy instance and replace it automatically, and we scale by adding replicas rather than by leaning on one large machine. There is no single instance whose failure takes the service down.

We started, like most products should, on a single server. As traffic grew we moved the stateful parts onto managed services and the app and worker onto orchestrated, multi-instance infrastructure, so scaling and recovery are routine operations rather than emergencies. The stack stayed the same size on paper; each part just stopped being a single point of failure.

Deliverability is part of reliability

For an email API, "reliable" is not only "the server is up." It is "the message reaches the inbox." So the same discipline runs through the sending path:

• DKIM, SPF, and DMARC are enforced at domain verification. You cannot send from a domain that has not passed authentication, which is the single biggest reason first emails land in spam.
• List-Unsubscribe and List-Unsubscribe-Post on every send, so you meet the Gmail and Yahoo bulk-sender requirements without wiring anything up yourself.
• Bounces and complaints flow back through SES and into your dashboard, so a bad address or a spam report is visible and your sender reputation stays protected.

The takeaway

Boring is a feature. The SMTPfast stack is small enough that we can reason about it end to end, each piece does exactly one job, and the parts that are genuinely hard, global delivery and durability, ride on infrastructure engineered to be reliable. That is not a compromise we are apologizing for. It is why we are comfortable putting your transactional email on it.

If you want to see it work, send your first email in about ten minutes. The whole point is that there is not much to learn.