Email System — Transactional & Bulk Delivery

Email delivery systems are a staple of system design interviews because they combine asynchronous processing, pipeline architecture, compliance requirements, and scale challenges into a single problem. Interviewers expect candidates to reason about the difference between transactional emails (password resets, order confirmations) and bulk campaigns (marketing newsletters), and how a single architecture can handle both workloads with very different traffic patterns and latency requirements.

At production scale, services like Amazon SES, Mailchimp, and SendGrid process over one billion emails per day. Transactional traffic runs at a steady 12,000 messages per second, while bulk campaign bursts can spike to 165,000 messages per second for 10-minute windows when a large campaign is triggered. The system must absorb these bursts gracefully without dropping messages or degrading transactional email latency, which users expect to arrive within seconds.

The core challenges include building a multi-stage processing pipeline where each stage scales and retries independently, implementing suppression list checks for CAN-SPAM and GDPR compliance, maintaining sender reputation with ISPs through proper bounce and complaint handling, rendering dynamic templates with per-recipient personalization at high throughput, and tracking the delivery lifecycle of every message from submission through delivery or bounce. A poorly designed email system risks blacklisting by major ISPs, which can take weeks or months to recover from.

The architecture implements a multi-stage pipeline with per-stage Kafka queues, enabling each processing step to scale, retry, and apply backpressure independently. The three stages are: submit (API acceptance and validation), render (template hydration with per-recipient variables), and send (suppression check followed by SMTP delivery). This separation is the standard pattern used by SES, SendGrid, and Mailchimp.

The request flow starts when an application client submits an email or campaign via the REST API. The API Gateway authenticates the request and enforces per-tenant rate limits. The SubmitService validates the payload, generates a unique message ID, returns 202 Accepted immediately (async acknowledgment), and publishes the message to the SubmitStream Kafka topic. For bulk campaigns, the SubmitService fans out the recipient list into individual messages. This decouples API response time from actual delivery, keeping submit latency under 50ms even during campaign bursts.

RenderWorker consumes from SubmitStream, fetches the email template from TemplateCache (Redis with 98% hit rate), hydrates it with per-recipient variables, and publishes the rendered email to RenderStream. The final stage, SendWorker, consumes rendered emails, checks each recipient against the SuppressionCache (a Bloom filter of 10 billion suppressed addresses using 12GB of Redis memory), and delivers via SMTP if the address is not suppressed. Every state transition is recorded in EventDB (DynamoDB) for full delivery lifecycle tracking. The per-stage queue design means a slow ISP during delivery does not block template rendering, and a rendering bug does not prevent already-rendered emails from being delivered.