Design an email service

Design a large email provider like Gmail or Outlook.com: hundreds of millions of mailboxes, mail arriving from the whole internet over a protocol from 1982, most of it spam, and users who expect search across years of mail to be instant on every device.

1. The prompt

"Design an email service: users send and receive email with anyone on the internet, organise it with labels or folders, search it, and use it on the web and on phones."

What makes it hard:

• You don't control the other side. Mail arrives over SMTP from millions of servers, many hostile; outgoing mail is judged by other providers' filters.
• Storage is enormous and per-user: years of mail and attachments for every account.
• Search and sync must feel instant on top of all that.

2. Frame the problem

3. What it must do

1. A user receives email from anyone on the internet, filtered for spam and malware, in their inbox within seconds.
2. A user sends email to anyone, and it's delivered (or they learn why not).
3. A user reads, labels and searches their mail on any device, kept in sync.

Not now: calendar and contacts, end-to-end encryption, mailing-list hosting, ads.

4. How well it must do it

5. Numbers that change the design

Illustrative numbers. Skipped: send volume (small compared with inbound).

6. The nouns

• Mailbox (one per user) with labels.
• Message: immutable content (headers, body, attachments) plus mutable state (labels, read, starred).
• Thread: messages grouped as a conversation.
• Change log: every change to a mailbox, numbered, for sync.

message        (user_id, message_id) → thread_id, labels[], flags, received_at, size, blob_ref, snippet
blob           sha256 → compressed body or attachment bytes             (object storage, shared across users)
thread         (user_id, thread_id) → subject, message_ids[], last_activity
change_log     (user_id, modseq) → kind (added | labels_changed | deleted), message_id
search_index   per user partition: term → postings of message_ids

7. The contract

Internet-facing
  SMTP (port 25): receive from other providers;  STARTTLS, MTA-STS for encryption policy
  SMTP submission (port 587): our users' clients send through us, authenticated
  IMAP: third-party clients

Our apps (JMAP-style JSON API)
  GET  /v1/mailboxes/me/messages?label=INBOX&page_token=…          → summaries
  GET  /v1/messages/{id}                                        → full message
  POST /v1/messages/{id}/labels   {add[], remove[]}
  GET  /v1/search?q=invoice from:acme after:2025-01-01
  GET  /v1/changes?since_modseq=8841                             → changes, new modseq
  POST /v1/messages:send   {to[], subject, body, attachments[]}  Idempotency-Key: …
  Push: a WebSocket or mobile push "mailbox changed" signal; clients then fetch changes

The user comes from the session token. Sync is "give me everything since change number N", which works for a phone that was offline for a minute or a month.

Data flow (inbound): SMTP edge (reputation, rate limits) → accept into a durable queue → authenticate sender (SPF, DKIM, DMARC) → spam and malware scoring → store blobs → write message metadata and change log → index for search → push to devices.

8. First working version

SMTP servers, a durable delivery queue, a filtering stage, mailbox storage sharded by user, a search indexer, and an API with sync and push.

8.1 Receiving a message

The SMTP server says "250 OK" only after the message is written to a replicated queue: that's the durability promise. Everything after (filtering, storage, indexing) runs from the queue and can retry.

8.2 Sending a message

Outgoing mail is signed with DKIM, put on an outbound queue per destination domain, and delivered over SMTP to the recipient's provider (found through its MX record). Temporary failures are retried with backoff for up to a few days; permanent ones produce a bounce message to the sender.

8.3 Reading and syncing

A client lists the inbox from message metadata (labels, snippet, date) and fetches bodies from object storage only when opened. Every change bumps the mailbox's change number; devices ask for changes since their last number, so a label applied on the laptop shows up on the phone.

9. Make it hold up

9.1 Filtering 20 billion messages a day security · cost

The threshold between "inbox" and "spam folder" trades missed spam against misfiled real mail; that trade-off is tuned per message category, and messages that fail authentication for a domain that publishes a strict policy are treated much more harshly.

9.2 Who really sent this? security

• SPF: the sender's domain publishes which IP addresses may send its mail; we check the connecting IP against the envelope sender's domain.
• DKIM: the sending server signs headers and body; we verify the signature with a public key in the signing domain's DNS.
• DMARC: passes if SPF or DKIM passes for a domain aligned with the visible From address; the From domain's policy says what to do otherwise (none, quarantine, reject), and where to send reports.
• ARC preserves authentication results across forwarders and mailing lists that would otherwise break them.

Try the scenarios in the lab in section 13: forwarding breaks SPF but usually not DKIM; a mailing list that edits the subject breaks DKIM.

9.3 An exabyte of mail cost · data safety

Deduplicated blobs need reference counting (or periodic mark-and-sweep) so a shared attachment is deleted only when no mailbox references it.

9.4 Search over years of mail search

Build an inverted index per user (or per small group of users in one index shard), updated asynchronously at delivery from the queue. Queries touch only one user's index, so they're small even when the total corpus is huge. Structured operators (from:, has:attachment, label:, dates) are fields in the same index. Recent mail is in a small, fast-updating segment; older segments are merged in the background, as in any search engine (Module 12).

9.5 Getting our mail delivered delivery

• Reputation: other providers judge our sending IPs and domains. Separate pools for different kinds of mail, warm up new IPs slowly, and stop spammers using our accounts (outbound spam scoring, send limits for new accounts).
• Authenticate everything we send: SPF, DKIM signatures, a DMARC policy.
• Queue per destination domain with its own rate limits and backoff, so one slow provider doesn't hold up the rest.
• Encrypt in transit with STARTTLS, and honour recipients' MTA-STS policies that require it.

9.6 Sync and push for hundreds of millions of devices delivery speed

Devices don't poll every few seconds. Phones get a platform push notification; web clients hold a connection (WebSocket or long poll) to a gateway that subscribes to their user's change events. Either way, the signal only says "something changed", and the client fetches the delta from the change log. Change logs are trimmed after some weeks; a device that's further behind does a full resync.

9.7 The whole design after the deep dives

10. Interviewer follow-ups

11. When things break

12. Wrap-up and the clock

Trade-offs we made:

• Acknowledge SMTP only after a durable queue write; process asynchronously.
• A filtering funnel from cheap to expensive.
• Metadata in sharded databases, content in object storage, deduplicated.
• Everything partitioned by user: mailbox, change log, search index.
• Push a signal, sync the delta.

What we'd watch: inbound queue age · time from acceptance to inbox (p99) · spam reports and "not spam" rescues · search latency and index lag · outbound bounce and deferral rates per destination · storage per user and dedup ratio.

At 10×: more shards everywhere; the per-user partitioning keeps it linear. Spam volume grows faster than users, so the funnel's early stages matter most.

Common mistakes:

• Ignoring that most inbound mail is spam.
• Saying "250 OK" before the message is durable.
• Storing message bodies in the main database.
• One global search index queried for every user.
• Clients polling for new mail.
• Forgetting outbound reputation.

13. Try it, check yourself, read more

Who sent this? An authentication lab. Pick a delivery scenario and see how SPF, DKIM and DMARC judge it. The visible From address is billing@bank.example, and bank.example publishes p=reject.

Simplified: real receivers also use ARC, reputation and content signals. "Aligned" means the authenticated domain matches the From domain (relaxed alignment allows subdomains).