Back to Engineering Blog/Engineering & Architecture
Engineering & Architecture

How We Built a Sub-50ms Email Sending Engine with KumoMTA, Postgres Outbox, and Lua

A deep architectural walkthrough of how SendOFF achieves sub-50ms transactional email latency with zero email loss across worker crashes.

Ajay Sharma
Ajay Sharma
Principal Systems Architect
Oct 15, 2026•16 min read

The Fallacy of Redis-Only Queues

Many naive email architectures place an HTTP API directly in front of a Redis BullMQ queue:

terminalSendOFF Verified
Client -> API -> Redis.lpush('emails', payload) -> Worker -> SMTP

This setup looks fast in synthetic benchmarks, but it harbors a fatal design flaw: Redis is not a persistent database of record. If the Redis node experiences an out-of-memory crash, an ungraceful restart, or a network partition, in-flight emails are lost forever. For transactional OTPs and password resets, losing emails means locked-out users.


The Postgres Transactional Outbox Pattern

To guarantee zero lost emails under any failure condition, SendOFF implements the Transactional Outbox Pattern:

sqlSendOFF Verified
-- Every send creates an atomic outbox record in Postgres first
INSERT INTO emails (
  id, team_id, from_email, to_email, subject, body_html, status, lane
) VALUES (
  $1, $2, $3, $4, $5, $6, 'queued', 'transactional'
) RETURNING id;
  • The API writes synchronously to Postgres with row-level security.
  • In the same database transaction, a lightweight message pointer is scheduled into Redis for instant sub-millisecond pickup.
  • If Redis crashes, SendOFF’s background Reconciler Worker runs an atomic query:
  • sqlSendOFF Verified
    SELECT id FROM emails 
    WHERE status = 'queued' 
      AND created_at < NOW() - INTERVAL '30 seconds'
    FOR UPDATE SKIP LOCKED;

    This guarantees at-least-once delivery with zero dropped messages.


    Inside KumoMTA: High-Concurrency Rust Daemon

    Rather than relying on legacy Postfix or Exim instances, SendOFF operates KumoMTA, an open-source Rust MTA specifically built for modern cloud workloads.

    Key architectural advantages of KumoMTA:

  • Lock-Free Concurrency: Leverages Tokio async runtimes to sustain 100,000+ concurrent outbound TCP handshakes.
  • Dynamic Connection Pooling: Keeps pre-warmed TLS connections open to Google and Microsoft MX endpoints, cutting connection setup overhead from 140ms to 4ms.
  • Embedded Lua Policy Engine: Enables routing rules to be evaluated in-process without slow external database queries.

  • Dynamic Routing with Lua Policies

    Our KumoMTA delivery policy dynamically splits traffic based on domain reputation and lane priority:

    luaSendOFF Verified
    -- KumoMTA policy.lua snippet
    kumo.on('smtp_server_message_received', function(msg)
      local lane = msg:get_meta('lane') or 'transactional'
      
      if lane == 'transactional' then
        -- Route to high-priority transactional egress pool with instant dispatch
        msg:set_meta('routing_domain', 'egress-fastlane.sendoff.in')
        msg:set_meta('max_connection_rate', '500/s')
      else
        -- Bulk lane with algorithmic throttle to preserve IP warmth
        msg:set_meta('routing_domain', 'egress-bulk.sendoff.in')
        msg:set_meta('max_connection_rate', '50/s')
      end
    end)

    This ensures that regardless of marketing volume spikes, the transactional lane maintains uninterrupted sub-50ms wire speed.

    Topics:#KumoMTA#Postgres Outbox#Lua#Systems Engineering#Performance
    Ajay Sharma

    Ajay Sharma

    Engineering Lead at SendOFF. Specializing in bare-metal KumoMTA socket tuning, dual-lane deliverability infrastructure, and low-latency API systems.