Build a system to send 1M personalized emails in 2 hours

WHAT THIS TESTS: This question evaluates whether you can design a high-throughput, fault-tolerant distributed pipeline that interfaces with an external provider whose reliability and rate limits you do not control. The interviewer cares about backpressure, observability, deliverability reputation, and idempotency under a concrete SLA of one million emails in two hours, which is roughly 139 emails per second sustained, with bursts likely higher.

A GOOD ANSWER COVERS: First, an async ingestion layer, typically an API gateway that validates requests and drops them onto a partitioned message queue such as Kafka, RabbitMQ, or SQS, where partitioning by recipient domain or campaign ID prevents head-of-line blocking. Second, auto-scaling worker pools that consume from the queue in batches; workers should be stateless and horizontally scalable, with concurrency tuned to the ESP throughput limits. Third, multi-layer rate limiting using token buckets or leaky buckets at the gateway per sender, per ESP account, and per destination domain to avoid throttling and blacklisting. Fourth, IP warmup and rotation using a pool of dedicated IPs, starting with low volumes and gradually increasing to build sender reputation, then distributing load across the pool with round-robin or weighted rotation. Fifth, transient failure handling with exponential backoff and jitter for 5xx or 429 responses, a dead-letter queue for permanent failures like 4xx invalid addresses, and circuit breakers to stop hammering a degraded ESP endpoint. Sixth, idempotency keys so duplicate sends do not happen across retries.

COMMON WRONG ANSWERS: Proposing a single monolithic application that synchronously calls the ESP API for each email will immediately fail on volume and latency. Ignoring IP warmup and sending a million emails from a cold IP will trigger spam filters and domain blacklisting. Treating all API errors as final without distinguishing 4xx client errors from 5xx server errors shows poor operational design. Overlooking queue partitioning leads to a single slow domain stalling the entire pipeline.

LIKELY FOLLOW-UPS: How would you change the design if the ESP enforces a 100 emails per second hard cap? How do you prevent duplicate sends if a worker crashes mid-batch? How do you handle unsubscribe and bounce feedback loops in real time? What metrics would you alert on, and what are your SLOs for delivery latency?

ONE CONCRETE EXAMPLE: Suppose your ESP returns a 429 Too Many Requests at 9:05 AM during a flash sale. Your worker should catch this, pause the specific partition for 30 seconds with exponential backoff, and requeue the batch while other workers continue processing different domains. Meanwhile, your circuit breaker opens after five consecutive 5xx errors, routing traffic to a secondary ESP or IP pool. If the same email ID is retried three times, the worker checks an idempotency store such as Redis before reattempting, ensuring the user receives exactly one message. Your monitoring stack tracks queue depth, send latency, bounce rate per IP, and ESP error codes, paging you if the queue depth exceeds a 15-minute processing buffer.