Design Gmail

Three surfaces: the SMTP edge (internet-facing protocol, not HTTP), the web/mobile API (HTTP+JSON for client apps), and IMAP/POP (legacy clients). Real engineering attention goes into SMTP edge and the web API.

The system has a distinctive shape: an SMTP edge fleet facing the hostile internet, a spam + policy layer that decides accept/reject/quarantine, a per-user mailbox store (sharded by user_id) holding messages + labels + thread data, and a search index per user. An outbound SMTP fleet handles send-mail with delivery reputation management.

When a mail lands at smtp.gmail.com:25, these steps run before we even store the message:

1. Connection-level check. Sender IP reputation lookup. Known bad-actor networks get 4xx temp-fail (forces retry from clean IPs) or hard reject.
2. SMTP handshake. Standard SMTP. During MAIL FROM, sender's domain SPF record is checked — "is this IP authorized to send for this domain?" Failures flagged or rejected based on DMARC policy.
3. DATA phase. Accept message bytes. On body completion, verify DKIM signature (cryptographic proof the domain owner signed this message). Unsigned or invalid signatures heavily penalized by spam classifier.
4. Spam classifier. ML model reads headers + body features (links, suspicious TLDs, phrase patterns, sender reputation, recipient engagement history with this sender, etc.). Output: {spam_prob, phishing_prob, label}.
5. Attachment + URL scanning. Attachments run through VirusTotal-equivalent in-house scanner. URLs checked against Google Safe Browsing. Phishing URLs trigger rewrite to warning interstitial.
6. Routing decision. Accept (→ inbox), accept-to-spam (→ spam folder), reject (4xx temp or 5xx hard). Non-accepts return over SMTP so sending server knows.
7. Storage write. Accepted messages written to per-user mailbox (sharded by recipient user_id). Thread computed from headers (In-Reply-To + References + subject-similarity heuristics). Search index updated.
8. Notify. Push notification to device if user has app installed; IMAP IDLE for long-polling mail clients.

sequenceDiagram
    participant S as Sender MTA
    participant E as SMTP edge
    participant F as Spam / virus
    participant M as Mailbox svc
    participant IX as Search index
    participant N as Notify

    S->>E: CONNECT + HELO
    E->>E: IP rep lookup
    S->>E: MAIL FROM + RCPT TO
    E->>E: SPF + DMARC check
    S->>E: DATA (headers+body)
    E->>E: DKIM verify
    E->>F: score message
    alt accept to inbox
        F-->>E: ham
        E->>M: store for user
        M->>IX: index body
        M->>N: fanout event
        E-->>S: 250 OK
    else accept to spam
        F-->>E: spam
        E->>M: store to SPAM label
        E-->>S: 250 OK (quiet)
    else reject
        F-->>E: malware / policy
        E-->>S: 550 Rejected
    end
          

Per-user mailbox shard. Bigtable row key is something like user_id#inv_ts#msg_id — so all messages for a user are co-located and scanning the inbox by time is a cheap range read. Labels stored as a separate indexed table (user_id#label#inv_ts#msg_id → msg_id) so "all messages with label=Work" is also a range read.

Search. Each user has their own inverted index. A query "from:boss receipt" intersects the "from:boss" posting list with the "receipt" posting list, restricted to that user's corpus. Indexes live in a separate service; built asynchronously after message ingest (≤ few seconds lag). Google's custom Zanzibar-style ACL applies — never search across users.

Outbound reputation. To send email that actually lands in inboxes (not spam folders at the recipient), Gmail must maintain pristine IP reputation. Outbound fleet sends from dedicated IPs with SPF + DKIM signing. Rate limits per sending-user. Bulk senders (marketing accounts) are flagged and throttled. Gmail's deliverability advantage is maintained by aggressively shutting down senders who get reported as spam.

• Labels vs folders. Gmail's big bet. Folders are hierarchical single-placement; labels are multi-valued. Enables "archive but I'll find it via search" — a UX that requires reliable fast search. Folders are storage-cheap; labels require reverse index.
• Per-user sharding vs domain sharding. Per-user is simpler for consistency + per-user quotas + privacy boundaries. Domain sharding is natural for corporate Workspace. Gmail does per-user + domain-aware routing.
• Threading algorithm quality. In-Reply-To/References is RFC-compliant. But email clients strip these fields; same-subject heuristics needed as fallback. Each added heuristic has false-positive risk. Interview-worthy because it's never fully solved.
• Attachments inline vs separate. Separate: dedup across messages (same PDF attached to 100 forwards = 1 copy). Inline costs more storage. Gmail stores separate + dedup + garbage-collects when all refs gone.
• Accept-and-filter vs reject-at-SMTP. Accept + filter to spam folder = better user experience (can recover). Reject = defends sender reputation. Gmail does both: soft-spam to folder for maybe-spam, hard-reject for obvious malware / IP-reputation-bad.