Why We Built Email Infrastructure on the Edge

When we set out to build a transactional email service, we had a choice: deploy on containers like everyone else, or build on the edge. We chose the edge — and here's why.

The problem with containers for email

Traditional email infrastructure runs on always-on servers. That means you're paying for compute even when no emails are being sent. Cold starts can take 200–500ms, and you're limited to one or two regions.

For email, latency matters. A 500ms delay between API ingestion and SES handoff might not sound like much, but it adds up — especially for high-volume senders who expect sub-second delivery guarantees.

Why Cloudflare Workers

Cloudflare Workers give us:

• ~10ms cold starts — WASM modules start almost instantly
• 300+ edge locations — your API is within 50ms of every developer on Earth
• Per-request billing — no idle servers, no wasted compute
• Automatic scaling — from 10 to 10 million emails

We compile Rust to WASM, which means we get the safety and performance of Rust without the overhead of a traditional runtime. No garbage collector pauses, no shared memory issues.

The architecture

Every incoming API request hits a Cloudflare Worker at the nearest edge node. The Worker validates the payload, checks rate limits via a Durable Object, and hands the message to a Queue. The sender Worker picks it up, signs the SES request with SigV4 (pure WASM, no AWS SDK), and fires it off to SES.

The entire pipeline — from API ingestion to SES handoff — takes under 50ms. That's not a theoretical number; it's measured in production across all regions.

What this means for you

Faster emails. Lower latency. No infrastructure to manage. And a pricing model that doesn't penalize you for quiet hours.

We'll share more benchmarks soon, but if you're curious about the numbers, check out our benchmarks page.