System Design 20: Design an Email Delivery System (Gmail / Outlook)

1. Overview and Core Problem Statement

Designing a hyper-scale email delivery platform like Gmail or Outlook requires orchestrating billions of users, high-throughput asynchronous message processing, distributed storage systems, and complex cross-domain networking protocols. An email system must support end-to-end user onboarding, rich text composition, draft persistence, attachment handling, advanced thread replies, and instant free-text search across petabytes of stored mail data.

2. Functional Requirements

The core functional scope defines what the user and the system must achieve during normal operational workflows:

• User Onboarding & Management: Users must be able to register unique email addresses and maintain user profiles.
• Send & Receive Mail: Support sending and receiving emails to single or multiple concurrent recipients across internal and external domains.
• Folders & File Structures: Provide hierarchical folder views (Inbox, Drafts, Sent Items, Trash) based on message status and categories.
• Search Engine: Allow users to query and search emails based on keywords, subject lines, and metadata.
• Attachments: Enable uploading and sending file attachments (PDFs, Word documents, images).
• Threading & Replies: Maintain conversation threads and reply chains associated with specific emails.

3. Non-Functional Requirements & CAP Theorem Strategy

Scale and characteristics dictate the foundational architecture of distributed email services:

• Massive Scale: Designed to handle over 1.5 billion active users and process billions of emails daily.
• High Availability vs. Consistency (CAP Theorem Trade-Off):
  • System-wide Availability: Email viewing and sending must remain highly available to prevent user lockouts.
  • User Onboarding Consistency: Registration requires strong consistency to ensure email address uniqueness globally. No two users can claim the same email handle.
  • Email Delivery Consistency: Email transmission favors eventual consistency (slight propagation delays are acceptable).
• Reliability & Durability: Sent and received emails must never be lost or accidentally deleted.

4. Core Entities Identified

Based on the functional requirements, the primary data domains include:

1. User: Profile, unique email handle, password hash, and status.
2. Email / Message: Subject, body, sender, recipient arrays (To, CC, BCC), timestamps, and status flags.
3. Threads & Replies: Conversation grouping IDs linking parent messages to replies.
4. Metadata: Attachment IDs, security scan flags, policy check results, and delivery status.

5. API Design & Public REST Endpoints

Public endpoints handle client interactions while decoupling heavy payloads to prevent connection timeouts.

6. High-Level Architecture

The high-level design separates client traffic routing, onboarding, draft composition, mail dispatch, and search querying.

7. Deep-Dive Design: User Service & Auto-Suggestion Caching

Managing 1.5 billion users requires optimized lookup patterns and sharded database clusters.

The 5 Auto-Suggestion Scenarios

1. Unknown Recipient (First Time): Complete email address required; no auto-suggestion.
2. Outside Domain (First Time): External domain unknown to local cache; no auto-suggestion.
3. Previously Emailed External Address: Recognized from historical sent logs; auto-suggestion triggered.
4. Google Contacts Match: Email exists in local contacts cache; auto-suggestion triggered.
5. Internal Domain Info Card: Local domain user displays rich metadata info cards upon Enter key validation.

Database Sharding & Consistent Hashing

To prevent single database bottlenecks across 1.5 billion records:

• Sharding Strategy: User email strings are hashed and modularized across database instances.
• Consistent Hashing: Utilizing a hashing ring prevents catastrophic cache misses when scaling shard clusters from $N$ to $N+1$ nodes.
• Primary Key Enforcement: The email_id serves as the primary key constraint to eliminate concurrent registration collisions.

8. Deep-Dive Design: Draft Composition & Attachment Handling

To avoid request timeouts from heavy payloads, attachment uploads are decoupled from email submission.

• Draft Storage: Text bodies and recipient lists are stored in the Draft Database.
• Blob Storage: Heavy files (PDFs, videos, executables) bypass application servers and upload directly to S3 via pre-signed URLs using multipart chunking.

9. Deep-Dive Design: Outbox Pattern, CDC, and Asynchronous Orchestration

When a user clicks Send, the system guarantees delivery durability using the Outbox Pattern and event streaming.

Validation DB & Asynchronous Checks

• Validation DB: Tracks message validation flags (spam_check, policy_check, attachment_check) asynchronously to prevent thread blocking if a validation microservice goes down.
• Precomputed Attachment Scanning: S3 uploads trigger asynchronous malware scans immediately upon upload, saving results in an S3 Validation DB so the send pipeline only reads cached verdicts.

10. Deep-Dive Design: SMTP Protocol Flow & External Relaying

When transmitting mail to external domains (e.g., Gmail to Outlook), the SMTP Relay Worker executes a precise network handshake protocol over TCP Port 25.

• MX Caching: MX record lookups are cached locally to minimize DNS query overhead.
• Bounce Handling: If the recipient validation step returns an invalid mailbox error, the transaction terminates and a bounce notification is triggered.

11. Deep-Dive Design: Search Engine Architecture & Aggregation

To provide instant free-text searching across millions of emails:

• Database Separation: Mail bodies reside in the Mailbox DB, while headers and metadata reside in the Metadata DB.
• Aggregator Service: Asynchronously joins content and metadata tables into unified document formats before ingestion into Elasticsearch, ensuring high-performance search queries without runtime database joins.

12. Summary and Key Takeaways

• User Unboarding: Requires strong consistency and primary key constraints on email handles to guarantee global uniqueness.
• CAP Theorem Balance: High availability is prioritized for core mail sending and receiving, while onboarding enforces strict consistency.
• Decoupled Uploads: Direct S3 multipart uploads via pre-signed URLs prevent application server bottlenecks and payload timeouts.
• Outbox Pattern: Ensures durability and zero message loss by persisting outbound states before publishing to Kafka event brokers.
• Asynchronous Orchestration: Validation pipelines run asynchronously, backed by a Validation DB to tolerate downstream service outages.
• SMTP Protocol Mechanics: External mail exchange relies on TCP Port 25 handshakes, MX priority routing, and explicit recipient validation.
• Optimized Search: Elasticsearch powered by an asynchronous aggregator service provides millisecond-latency free-text searches across split content and metadata stores.