Designing an Email Service at Scale

How do you build a distributed platform that handles 1 billion users, 50 billion daily messages, and petabytes of storage with zero data loss?

Dive into the complete engineering breakdown here:
https://engineering.by-tech.workers.dev/articles/designing-an-email-service/

At a high level, modern email architecture operates as two independent, one-way pipelines bridging legacy protocols and cloud-native systems:

1. Outbound Delivery: Users submit messages via HTTPS REST APIs, where payloads are immediately offloaded to S3. Delivery tasks are queued in Kafka, and outbound workers manage DKIM signing and DNS MX resolution before delivering over SMTP.

2. Inbound Ingestion: Edge gateways terminate global Anycast connections on port 25 and perform lightweight SPF/DMARC checks. Heavy message bodies stream to S3, while a Kafka claim-check pointer triggers deep scanning, Cassandra metadata writes, and real-time WebSocket pushes to active devices.

Key technical constraints discussed in the article:

1. The Custody Contract: Why returning an SMTP 250 OK is an irreversible legal commitment that must wait for multi-AZ Kafka replication.

2. The Dual-Write Trap: How using a single-partition Cassandra atomic batch for transactional outboxes guarantees emails are never saved without also being queued for delivery.

3. Backscatter Prevention: How sending an automated bounce to a forged address can instantly get your outbound IP blacklisted by major ISPs.

4. Data Modeling: Sharding Cassandra by user_id and monthly time buckets to keep read latency under 200ms without unbounded partition growth.