Cruxly › System design › Design Exercises

Bulk Email Delivery

reputation, not throughput, is the actual constraint

Prompt: design a system that sends transactional and bulk marketing email on behalf of many customers — millions of emails a day, with delivery tracking (bounces, opens, spam complaints) fed back to the sender.

40 minutes first. Sending an email is one API call. Getting it into the inbox, repeatedly, at scale, without every major mail provider deciding to block you, is the actual exercise.

Applying the four moves: Scope — transactional and bulk sending for many customers, with bounce/open/complaint feedback; template editing out. Estimate — millions of emails per day, but the binding constraint is per-receiving-provider rate limits and sender reputation, not your own throughput. Sketch — an intake API, per-customer queues, sending infrastructure with dedicated IPs, and an inbound feedback processor. Deep dive — deliverability: one customer's spam complaints damage a shared IP's reputation for everyone, so the design isolates customers, warms new IPs gradually, honours suppression lists, and authenticates mail (SPF/DKIM/DMARC).

Why this isn't a throughput problem

Scope. In scope: sending infrastructure, bounce/complaint feedback handling, sender reputation management, retry/backoff for transient failures. Out of scope: the actual email content/template rendering, marketing-campaign scheduling logic.

Sending capacity was never the hard constraint — mail servers can push enormous volume. The actual constraint is that every major mail provider (Gmail, Outlook, Yahoo) maintains a reputation score for every sending IP address and sending domain, based on bounce rates, spam complaint rates, and engagement patterns, and that score determines whether subsequent mail from that sender lands in the inbox, the spam folder, or gets silently dropped with no bounce at all. A design that optimizes purely for send throughput while ignoring reputation will, after enough volume, simply stop being delivered — the mail leaves the system successfully and vanishes into spam folders or silent drops, which looks like success from inside the system and is actually complete failure from the recipient's point of view.

IP warming and reputation isolation

Pooling by reputation risk contains the blast radius of one sender's mistake instead of letting it damage every sender behind the same IP.

A brand-new sending IP has no reputation history at all, and mail providers treat unknown senders with suspicion by default — sending high volume immediately from a fresh IP looks identical to a spam operation starting up, regardless of actual intent. IP warming (gradually ramping send volume over days to weeks, starting very low and increasing only as engagement signals stay healthy) is how a new sending IP earns a reputation, rather than being able to simply start at full volume.

Reputation is a shared resource across every customer sending from the same IP, which forces a pooling strategy. New or unverified customers share a pool of lower-volume, closely-monitored IPs; established, high-volume, good-reputation customers get dedicated IPs. This isolates one careless or malicious sender's reputation damage from every other customer — without pooling, one customer's bad campaign degrades deliverability for every other customer sharing that IP, an entirely unrelated-seeming customer's mail suddenly landing in spam because of someone else's behavior.

Feedback loops: bounces, complaints, and suppression lists

Hard bounces (invalid address, mailbox doesn't exist) must permanently suppress future sends to that address — continuing to send to addresses that reliably bounce is one of the most direct signals mail providers use to penalize sender reputation, so bounce handling isn't just bookkeeping, it's a first-class input to whether future mail gets delivered at all. A hard-bounced address added to a suppression list must be checked before every future send — the same "check before you act" discipline as this track's rate-limiter and idempotency-key patterns, here applied to "should this recipient even be attempted."

Spam complaints (a recipient clicking "report spam") are an even stronger negative signal than bounces, because it's a human's explicit judgment rather than an automated address-validity failure, and providers weight it accordingly. Feedback Loop (FBL) programs, run by major providers, forward these complaints back to the sending infrastructure in near-real-time specifically so senders can suppress that recipient immediately — a sender that keeps mailing someone who has actively complained accelerates reputation damage fast, so ingesting FBL data and acting on it immediately (not in a nightly batch) is a real design requirement, not a nice-to-have.

List hygiene has to be proactive, not purely reactive to bounces that already happened — engagement-based suppression (stop sending to addresses that haven't opened or clicked in, say, 6 months) removes low-engagement recipients before they generate a complaint or bounce, because provider reputation algorithms weight overall engagement rate, not just explicit negative signals, and a large stale, disengaged list drags down the aggregate engagement rate even without any bounces or complaints occurring.

Failure modes and the honest edges

Retrying a transient failure (a temporary "mailbox full" or a receiving server briefly unavailable) needs exponential backoff over hours to days, not immediate rapid retry — retrying too aggressively against a temporarily-struggling receiving server looks like exactly the kind of aggressive, unusual sending pattern that damages reputation, the opposite of the intended effect of trying to ensure delivery.

Authentication (SPF, DKIM, DMARC) is a prerequisite for reputation to even matter, not a separate concern — without correctly configured domain authentication records, a receiving mail server may not even trust that the mail genuinely comes from the claimed sending domain at all, independent of any reputation score. Naming these by name signals real familiarity with the domain, not just the reputation mechanics.

A sudden legitimate volume spike (a real customer's biggest sale of the year) looks identical, from a receiving provider's automated detection standpoint, to a compromised account suddenly sending spam — a system that can't distinguish "expected seasonal spike" from "account compromise" either blocks legitimate high-volume sending unnecessarily or fails to catch a real compromise. This is worth naming as a genuine, hard-to-fully-resolve ambiguity rather than a solved problem.

How to say it in the interview

"Any mail server can technically send a million emails an hour, so throughput was never the constraint — the real constraint is sender reputation, a score every major mail provider maintains about you that determines whether your mail lands in the inbox, the spam folder, or gets silently dropped, and one careless high-volume sender under the wrong IP can burn that reputation for everyone sharing it."

Checklist

Identified sender reputation, not send throughput, as the actual constraint on delivery at scale
Used gradual IP warming for new sending infrastructure rather than starting at full volume
Pooled customers by reputation risk to isolate one sender's damage from every other customer sharing an IP
Treated hard-bounce suppression as a first-class input to future delivery, not just bookkeeping
Checked the suppression list before every send, applying the same check-before-you-act discipline as rate limiting
Ingested Feedback Loop complaint data and acted on it immediately, not in a nightly batch
Added proactive engagement-based suppression rather than relying only on reactive bounce/complaint handling
Used exponential backoff over hours to days for transient failure retries, not rapid immediate retry
Named SPF, DKIM, and DMARC as prerequisites for reputation to matter at all, not a separate concern
Named the ambiguity between a legitimate volume spike and a compromised account as genuinely hard to resolve

Practice this interactively