Back🌐

Designing an Email Service

AWAKENING0 / 100
[░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]0%

Designing an Email Service

High Level Design·intermediate·~25 min read

  • system-design
  • email
  • distributed-systems
  • microservices
  • hld

What you'll learn

  • Problem Statement

    Design a large-scale email service like Gmail that handles 2 billion users. The system must support sending and receiving emails, searching through mailboxes, managing contacts and groups, detecting spam, and handling attachments — all w…

  • Requirements

  • Functional Requirements

    - Send and receive emails (internal and external) - Search emails by subject, body, sender, date - Manage contacts and contact groups - Spam and virus detection - Attachments (up to 25 MB) - Folders, labels, and filtering rules

  • Non-Functional Requirements

    - High availability (99.99% uptime) - Low latency for inbox loading ( {e-123, e-555, e-456} 2. Look up "meeting" -> {e-123, e-456, e-789} 3. Intersect -> {e-123, e-456} The search indexer consumer (from the Kafka pipeline) builds and upd…

  • SMTP vs IMAP

  • SMTP (Simple Mail Transfer Protocol)

    - Used for sending emails - Pushes email from sender's server to recipient's server - One-way: fire and send - Port 25 (server-to-server), Port 587 (client-to-server with auth)

  • IMAP (Internet Message Access Protocol)

    - Used for receiving/syncing emails - Client pulls emails from the server - Bidirectional: supports read/unread state, folder management, partial fetch - Port 993 (with TLS) For internal emails (both users on our platform), we skip SMTP…

  • Contacts Manager

  • Contact Table (Bidirectional)

    When Alice adds Bob as a contact, we create entries in both directions. This allows both users to see each other in their contact lists and enables features like "People you've emailed."

  • Group Table with Roles

    Role Permissions: | Role | Send to Group | Add Members | Remove Members | Delete Group | |------|:---:|:---:|:---:|:---:| | Creator | Yes | Yes | Yes | Yes | | Admin | Yes | Yes | Yes | No | | Member | Yes | No | No | No | | Guest | Yes…

  • Capacity Estimation

  • Starting Assumptions

    - 2 billion active users - 50 emails/user/day (sent + received) - Average email metadata: 2 KB - Average email content: 50 KB - Average attachment: 500 KB (but only 10% of emails have attachments)

  • Daily Load

    | Metric | Calculation | Result | |--------|-------------|--------| | Total emails/day | 2B x 50 | 100 billion | | Emails/second | 100B / 86400 | ~1.15 million | | Raw storage/day | 100B x 50KB | ~5 PB | | With dedup + compression (50%)…

  • Infrastructure Requirements

    | Component | Calculation | Result | |-----------|-------------|--------| | Virus detector processes | 1M emails/sec, each scan takes 6ms | ~6,000 processes | | Cache machines (Redis) | 2TB hot data, 16GB per machine | ~120 machines | |…

  • Design Evolution & Trade-offs

    How this system grew from an MVP to what a production version looks like — and the choices you'd defend in an interview. Email looks deceptively simple at MVP — "store rows, list rows" — but the system hits three very different walls in…

  • Stage 1 — MVP: One box, one database

    The simplest thing that could possibly work for email-service. Good enough for a startup pilot with a few thousand users on a single domain. - A single API server (monolith) exposing POST /send, GET /inbox, GET /email/:id. - A single rel…

  • Stage 2 — Scale-out: Multiple pods behind a load balancer

    - API layer becomes stateless; N replicas behind an L7 load balancer (nginx / ALB). - Sessions moved out of process memory into JWT (self-contained) or a Redis session store. - Attachments moved off local disk into S3 (or GCS) — the DB s…

  • Stage 3 — Bottleneck: Write fan-out and delivery pipeline

    The characteristic write-heavy problem for email is fan-out on receive. A single inbound message can produce hundreds of per-user inbox rows, plus index updates, plus spam scores, plus virus scans, plus push notifications. Doing this syn…

  • Cost vs Complexity — When to Pick What

    | Concern | MVP choice | Growth choice | Enterprise choice | |---------|-----------|---------------|-------------------| | Compute | Single VM running the monolith | K8s deployment, HPA on CPU | Multi-region K8s + spot fleets for consume…

  • Migration Path (MVP → Enterprise)

    A stepped list — how you'd migrate a live email system, in what order, and how to avoid downtime. Not everything has to happen at once, and several of these steps are independent. 1. Move attachments to S3. This is the cheapest and highe…

  • Complete Architecture Diagram

    ---

  • Key Design Decisions Summary

    | Decision | Rationale | |----------|-----------| | Separate metadata from content | Fast inbox loading without reading large bodies | | Event-driven pipeline (Kafka) | Decoupled processing, independent scaling, resilience | | Global cac…

← back to High Level Design

Designing an Email Service — High Level Design | GoCrack | GoCrack