How Would You Design a Large-Scale Email Delivery Service?
Design a scalable email delivery service: async queueing, sender reputation, bounce handling, and suppression lists explained.
Expected Interview Answer
A large-scale email service accepts send requests via an API, queues them for asynchronous delivery, routes through multiple outbound relays with reputation management, and tracks bounces, opens, and complaints via webhooks, all designed for high throughput and deliverability rather than instant synchronous sending.
Clients submit send requests to an API, which validates and persists the message, then enqueues it rather than sending synchronously, since actual SMTP delivery to a remote mail server can be slow or fail transiently. A pool of sending workers pulls from the queue and delivers via SMTP or a provider relay, applying per-domain rate limiting and IP/domain reputation warm-up to avoid being flagged as spam by receiving providers like Gmail or Outlook. Delivery outcomes (accepted, bounced, deferred) and later events (opens, clicks, spam complaints) are tracked, often via provider webhooks, and fed back into a suppression list so the system stops emailing addresses that hard-bounced or complained. For very high volume, the service shards by sending domain and maintains separate reputation pools, and uses retry with exponential backoff for soft bounces (mailbox full, temporary server error) while permanently suppressing hard bounces (invalid address).
- Asynchronous queueing absorbs bursts and isolates slow SMTP delivery from the API
- Reputation management (rate limits, IP warm-up) protects deliverability at scale
- Suppression lists prevent repeatedly emailing bounced or complained-about addresses
- Retry with backoff distinguishes recoverable soft bounces from permanent hard bounces
AI Mentor Explanation
An email service is like a stadium’s outward mail room handling thousands of fan letters after a match instead of the players personally walking each letter to the post office. Every letter (email) is dropped into a sorting tray (the queue) and a team of clerks processes them steadily, rather than one clerk trying to hand-deliver each one instantly. If an address on a letter is wrong, it is marked and future letters to that address stop being sent (suppression), while a temporarily closed post office just gets a retry later. That asynchronous, monitored dispatch with feedback on failures is exactly what an email service provides.
Step-by-Step Explanation
Step 1
Accept and enqueue
The API validates the send request, persists it, and enqueues it rather than sending synchronously.
Step 2
Deliver via reputation-managed workers
A worker pool sends via SMTP relays with per-domain rate limiting and IP/domain warm-up to protect sender reputation.
Step 3
Track delivery outcomes
Accepted, bounced, and deferred statuses are recorded; provider webhooks report opens, clicks, and spam complaints.
Step 4
Apply retries and suppression
Soft bounces retry with exponential backoff; hard bounces and complaints add the address to a permanent suppression list.
What Interviewer Expects
- Explains why sending is asynchronous/queued rather than synchronous
- Discusses sender reputation management: rate limiting, IP/domain warm-up
- Distinguishes soft bounces (retry) from hard bounces (suppress permanently)
- Mentions webhook-based tracking of opens, clicks, bounces, and complaints
Common Mistakes
- Sending synchronously inside the API request, causing slow or failed responses
- Not distinguishing soft bounces from hard bounces, retrying invalid addresses forever
- Ignoring sender reputation, causing the whole domain to be marked as spam
- Forgetting suppression lists, leading to repeatedly emailing complained or bounced addresses
Best Answer (HR Friendly)
“An email service accepts a request to send an email, puts it in a queue, and delivers it in the background rather than making the caller wait. It carefully manages sending reputation so emails do not get marked as spam, and it tracks bounces and complaints so we stop emailing addresses that are no longer valid.”
Code Example
async function handleSendRequest(req, res) {
const message = await validateAndPersist(req.body)
await sendQueue.enqueue({ messageId: message.id })
res.status(202).json({ messageId: message.id, status: "queued" })
}
async function deliveryWorker() {
while (true) {
const job = await sendQueue.dequeue()
const message = await store.get(job.messageId)
if (await isSuppressed(message.to)) {
await store.markSkipped(message.id, "suppressed")
continue
}
try {
await smtpRelay.send(message, { rateLimitKey: message.fromDomain })
await store.markSent(message.id)
} catch (err) {
if (err.isHardBounce) {
await suppressionList.add(message.to)
await store.markFailed(message.id, "hard_bounce")
} else {
await sendQueue.enqueueWithBackoff(job, err.retryCount)
}
}
}
}Follow-up Questions
- How would you warm up a brand-new sending IP or domain to build reputation?
- How do you handle a burst of 10 million emails without overwhelming receiving mail servers?
- What is the difference between SPF, DKIM, and DMARC, and why do they matter for deliverability?
- How would you design the suppression list to be checked efficiently before every send?
MCQ Practice
1. Why does an email service enqueue send requests instead of sending synchronously?
Delivery to remote mail servers is variable in latency and can fail transiently, so async queueing keeps the accepting API fast and decoupled.
2. What is the correct handling for a hard bounce (invalid address)?
A hard bounce indicates a permanently invalid address, so it should be added to a suppression list rather than retried.
3. Why does sender reputation management (rate limiting, IP warm-up) matter?
Mailbox providers score sending IPs and domains; poor reputation from bursts or complaints leads to throttling or spam-folder placement.
Flash Cards
Why queue email sends instead of sending synchronously? — SMTP delivery is slow/unreliable; queueing keeps the API fast and decoupled from delivery.
Soft bounce vs hard bounce? — Soft bounce is temporary (retry with backoff); hard bounce is permanent (suppress the address).
Why manage sender reputation? — Receiving providers use it to decide whether to deliver, throttle, or spam-flag your mail.
What is a suppression list? — A list of addresses (hard-bounced or complained) the system permanently stops emailing.