System Design Interview

Understand the Problem

Scope 3 min readLesson 1 of 4

In this chapter we design a large-scale email service, such as Gmail, Outlook, or Yahoo Mail. The growth of the internet has led to an explosion in the volume of emails. In 2020, Gmail had over 1.8 billion active users and Outlook had over 400 million users worldwide 1 2.

Figure 1 Popular email providers

Step 1 – Understand the problem and establish design scope

Over the years, email services have changed significantly in complexity and scale. A modern email service is a complex system with many features. There is no way we can design a real-world system in 45 minutes. So before jumping into the design, we definitely want to ask clarifying questions to narrow down the scope.

Clarifying the scope
Candidate

How many people use the product?

Interviewer

One billion users.

Candidate

I think the following features are important:

  • Authentication.

  • Send and receive emails.

  • Fetch all emails.

  • Filter emails by read and unread status.

  • Search emails by subject, sender, and body.

  • Anti-spam and anti-virus.

Interviewer

That’s a good list. We don’t need to worry about authentication. Let’s focus on the other features you mentioned.

Candidate

How do users connect with mail servers?

Interviewer

Traditionally, users connect with mail servers through native clients that use SMTP, POP, IMAP, and vendor-specific protocols. Those protocols are legacy to some extent, yet still very popular. For this interview, let’s assume HTTP is used for client and server communication.

Candidate

Can emails have attachments?

Interviewer

Yes.

Non-functional requirements

Next, let’s go over the most important non-functional requirements.

Reliability. We should not lose email data.

Availability. Email and user data should be automatically replicated across multiple nodes to ensure availability. Besides, the system should continue to function despite partial system failures.

Scalability. As the number of users grows, the system should be able to handle the increasing number of users and emails. The performance of the system should not degrade with more users or emails.

Flexibility and extensibility. A flexible/extensible system allows us to add new features or improve performance easily by adding new components. Traditional email protocols such as POP and IMAP have very limited functionality (more on this in high-level design). Therefore, we may need custom protocols to satisfy the flexibility and extensibility requirements.

Back-of-the-envelope estimation

Let’s do a back-of-the-envelope calculation to determine the scale and to discover some challenges our solution will need to address. By design, emails are storage heavy applications.

  • 1 billion users.

  • Assume the average number of emails a person sends per day is 10. QPS for sending emails = 10910^{9} * 10 / (10510^{5}) = 100,000.

  • Assume the average number of emails a person receives in a day is 40 3 and the average size of email metadata is 50KB. Metadata refers to everything related to an email, excluding attachment files.

  • Assume metadata is stored in a database. Storage requirement for maintaining metadata in 1 year: 1 billion users * 40 emails / day * 365 days * 50 KB = 730 PB.

  • Assume 20% of emails contain an attachment and the average attachment size is 500 KB.

  • Storage for attachments in 1 year is: 1 billion users * 40 emails / day * 365 days * 20% * 500 KB = 1,460 PB

From this back-of-the-envelope calculation, it’s clear we would deal with a lot of data. So, it’s likely that we need a distributed database solution.

Finished reading?

Mark it complete to track your progress.

PreviousWrap UpHotel Reservation SystemNext High-Level DesignDistributed Email Service