aiagent.org Official Logo aiagent.org

System Design Architectures

Interactive technical blueprints, capacity estimates, database sharding strategies, and visual flowcharts for the top 30 system design interview questions.

Target Architectures
Architecture Blueprint

Design Gmail

Resilient IMAP/POP3 email messaging service with multi-level storage tiers and spam filters.

1. System Requirements

Functional
  • Send and receive email messages with text, formatting, and file attachments.
  • Manage custom folder directories (Inboxes, Sent, Trash).
  • Filter spam emails and display presence/search indexes.
Non-Functional / SLA
  • High durability (no email files can be lost).
  • Near-instant inbox refresh indicators.

2. Scale & Resource Estimates

Throughput: 1 Billion Active Users. 100 Billion emails sent/day = 1.15 Million emails/sec average. Storage needs = petabytes/day.

Storage & RAM: 100B emails/day * 50 KB (including metadata) = 5 Petabytes/day storage. Requires storage tiering.

3. System API Endpoints

POST /api/v1/mail/send
Request: { to: "user@example.com", subject: "Meeting tomorrow", body: "Let's align at 9 AM." }
Response: { mail_id: "em-9304", status: "queued" }

4. Database Schema Design

Table: mailboxes (Cassandra - sharded by user_id)
- user_id (UUID - Partition Key)
- folder_id (VARCHAR)
- mail_id (TimeUUID - Clustering Key)
- sender (VARCHAR)
- subject (VARCHAR)
- preview (VARCHAR)
- body_ref_path (VARCHAR)

5. Interactive High-Level Architecture

graph TD Client[Mail Client] -->|SMTP Send| SMTPServer[SMTP Server] SMTPServer -->|Route Mail| Delivery[Mail Delivery Agent] Delivery -->|Spam scan| SpamFilter[Spam Filtering Engine] SpamFilter -->|Clean Mail| MailService[Mailbox Storage Service] MailService -->|Write Metadata| MailboxDB[(Cassandra Mail Store)] MailService -->|Write Attachment| BlobStore[(S3 Object Store)] MailService -->|Push Refresh| SyncService[Push Refresh Service] SyncService -->|SSE Refresh| Client

6. Scalability Deep Dive & Bottlenecks

Divided into Metadata Storage and Blob Storage. Email previews and header parameters are stored in Cassandra partitioned by `user_id` to allow instant inbox reads. Raw text contents and attachments are written to S3. To scale ingestion during email storms, incoming SMTP streams write to Kafka queues first, decoupling mail reception from spam filtering and document parsing.

7. Production Scaling Strategies

SMTP Ingestion Queue: Incoming SMTP connections write raw email bytes to Kafka (partitioned by recipient domain). Decouples mail reception from processing. During email storms (Black Friday, news alerts), Kafka absorbs 10M+ emails/sec burst without dropping connections.

Spam/Phishing ML Pipeline: Every incoming email passes through a multi-stage ML pipeline: (1) sender reputation check, (2) content classification (spam/ham), (3) phishing URL detection, (4) attachment malware scan. Pipeline latency budget: <500ms. 99.9% spam detection rate.

Inbox Partitioning: Cassandra inbox table partitioned by user_id. Each user's inbox is a single partition with emails as clustering rows (ordered by timestamp DESC). Inbox read = single partition scan. At 2B users, distribute across 500+ Cassandra nodes.

Attachment Blob Tiering: Recent attachments (last 30 days) on SSD-backed S3. Older attachments on S3 Infrequent Access (50% cost reduction). Attachments >1 year old moved to S3 Glacier (90% cost reduction). Retrieval from Glacier takes 3-5 minutes with user notification.

Search Index Sharding: Full-text email search powered by Elasticsearch. Index sharded by user_id for data isolation. Each user's search index holds ~50K emails. Queries scoped to a single shard — no cross-shard fan-out needed. Handles 500K search queries/sec.

Push Notification Fan-out: New email triggers push to all user devices (phone, tablet, desktop). Use Firebase Cloud Messaging (FCM) and Apple Push Notification Service (APNS). Batch notifications with 2-second debounce to avoid notification storms during mailing list bursts.

8. Runnable Production Starter Code

Scaffold