Design Email Delivery System

Email Delivery System Problem Framing and Clarifications

Email Delivery System is a real-time customer messaging platform where inbound user messages must appear in an agent inbox with deterministic ordering, low tail latency, and predictable assignment behavior under burst traffic. In an interview, this section demonstrates how we translate user-facing expectations (instant delivery, agent visibility, and reliable follow-up) into explicit architecture constraints. We intentionally tie design choices to operational consequences so the interviewer can see why each component exists.

The most important framing decision is that Email Delivery System is not just chat transport; it is a conversation operating system with inbox states, SLA timers, teammate workflows, and bot orchestration. That means the design must optimize for consistency of conversation state, not only raw message throughput. We therefore separate write-path durability from read-path fan-out and use asynchronous projections to maintain responsive inbox views while preserving source-of-truth event history.

For phase understanding, we explicitly call out where strong consistency is mandatory (assignment ownership, SLA transitions, billing actions) and where eventual consistency is acceptable (analytics widgets, secondary counters, search indexing lag). This distinction is a recurring interviewer checkpoint and prevents over-engineering expensive coordination where it is not needed.

Operationally, we guard against common failure patterns: duplicate message delivery, out-of-order websocket updates, stale agent presence, and replay during reconnect storms. The section uses concrete mitigation tactics including idempotency keys, monotonic sequence numbers, bounded retry with jitter, and dead-letter handling for poisoned events. These mechanisms make the architecture review-ready for staff-level discussion.

Why interviewers care

Email Delivery System interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

The failure that defines the design

The outage to narrate is the reputation collapse. A compromised account or a bad bulk send triggers a wave of spam complaints, the receiving mail providers (Gmail, Outlook) start throttling or blocking your sending IPs, and suddenly even legitimate transactional email from every other tenant on those IPs lands in spam or bounces. The fix is structural: isolate reputation by separating transactional and bulk IP pools, enforce per-account complaint-rate limits, honor unsubscribes durably, and warm IPs gradually. An email platform lives or dies on sender reputation with the receiving providers — a green accept rate means nothing if the mail is silently going to spam.