Skip to content
System Designer

Hard · Productivity

Email service

Mail arrives from the whole internet, including a lot of spam, and must land in the right inbox. People open, search, send and attach. Never lose a message, and keep search fast even over years of mail. Practise this hard system design problem for free with a Google or GitHub account.

The brief

Mail arrives from the whole internet, including a lot of spam, and must land in the right inbox. People open, search, send and attach. Never lose a message, and keep search fast even over years of mail.

Think of an email service like Gmail.

Users, scale and requirements

Who uses it
2 million people
Audience in plain numbers
2,000,000 users or devices
Normal peak
≈ 9,000 requests per second
Request mix
Read: 45%; Write: 40%; Search: 10%; Upload: 5%
Speed for 99 of 100 requests
Read: ≈ 300 ms; Write: ≈ 300 ms; Search: ≈ 300 ms; Upload: ≈ 3,000 ms
Successful requests
99.95%
Data safety
No acknowledged write may be lost.
Monthly budget
≈ $30,000
Data at rest
≈ 150 TB
Where users are
North America: 60%; Europe: 40%
Home region
North America
Waiting deadlines
Read: 900 seconds; Write: 3,600 seconds; Search: 900 seconds; Upload: 3,600 seconds
Minimum retained history
3,650 days on authoritative stores
Fresh reads
People must see their own changes. At most 0.1% of reads may be stale in the model.
Personal reads
95% of reads are private; a shared public copy cannot answer them.
Required proofs
Managed encryption keys; Tested backups

≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.

  • Most incoming mail is spam or bulk; the filter must be cheap per message (approx.).
  • Older mail lives in cheap storage: only the recent 150 TB is on fast disks.
  • Scored data retention: at least 3650 days on active authoritative stores. Copies used only for search or reports can be rebuilt. Local device history and rollup policies still require the separate protocol check.

Questions that shape the design

How quickly must a new email appear in the inbox?

Within a few seconds. A delay of a minute is noticeable, an hour is a bug.

Can search be a little behind?

A few seconds behind is fine. It must still find mail from ten years ago.

Do we keep old mail on fast disks?

No. Recent mail is hot, older mail moves to cheaper storage. Opening it may take a bit longer.

Do I see my sent mail at once?

Yes. A sent message must show in Sent immediately, even if delivery to the other side takes longer.

The traffic day

Traffic concentrated in working hours. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

  1. 10:00 · Bot scraping

    Bots try stolen passwords and scrape pages, adding unwanted traffic.

    Extra attack traffic is 0.5 times the configured peak. Duration: ≈ 7,200 seconds.

  2. 14:00 · Disk full

    Data or logs fill the disk. Writes stop until someone frees space.

    Lasts until detected and repaired.

  3. 18:00 · Replication lag

    Copies fall behind. Users read old data, even their own fresh changes.

    Copy lag: ≈ 30 seconds. Duration: ≈ 1,200 seconds.

What a strong design has to handle

  • A new email should be accepted fast and processed afterwards. What can hold the work in the middle?
  • Accept mail durably and keep mailbox delivery and search indexing retryable.
  • Filtering after queuing keeps accepting mail during a spam flood, but spam may reach inboxes a little later.
  • A separate search index costs extra storage but keeps heavy searches away from the mailbox.

Make a prediction, run a full traffic day, then compare the result. The in-game editorial opens after a finished day and includes measured reference designs.

Concepts to practise

Related problems