System Design Interview

Understand the Problem

Scope 2 min readLesson 1 of 4

In recent years, cloud storage services such as Google Drive, Dropbox, Microsoft OneDrive, and Apple iCloud have become very popular. In this chapter, you are asked to design Google Drive.

Let us take a moment to understand Google Drive before jumping into the design. Google Drive is a file storage and synchronization service that helps you store documents, photos, videos, and other files in the cloud. You can access your files from any computer, smartphone, and tablet. You can easily share those files with friends, family, and coworkers 1. Figure 1 and 15-2 show what Google drive looks like on a browser and mobile application, respectively.

Figure 1
Figure 2

Step 1 – Understand the problem and establish design scope

Designing a Google drive is a big project, so it is important to ask questions to narrow down the scope.

Clarifying the scope
Candidate

What are the most important features?

Interviewer

Upload and download files, file sync, and notifications.

Candidate

Is this a mobile app, a web app, or both?

Interviewer

Both.

Candidate

What are the supported file formats?

Interviewer

Any file type.

Candidate

Do files need to be encrypted?

Interviewer

Yes, files in the storage must be encrypted.

Candidate

Is there a file size limit?

Interviewer

Yes, files must be 10 GB or smaller.

Candidate

How many users does the product have?

Interviewer

10M DAU.

In this chapter, we focus on the following features:

  • Add files. The easiest way to add a file is to drag and drop a file into Google drive.

  • Download files.

  • Sync files across multiple devices. When a file is added to one device, it is automatically synced to other devices.

  • See file revisions.

  • Share files with your friends, family, and coworkers

  • Send a notification when a file is edited, deleted, or shared with you.

Features not discussed in this chapter include:

  • Google doc editing and collaboration. Google doc allows multiple people to edit the same document simultaneously. This is out of our design scope.

Other than clarifying requirements, it is important to understand non-functional requirements:

  • Reliability. Reliability is extremely important for a storage system. Data loss is unacceptable.

  • Fast sync speed. If file sync takes too much time, users will become impatient and abandon the product.

  • Bandwidth usage. If a product takes a lot of unnecessary network bandwidth, users will be unhappy, especially when they are on a mobile data plan.

  • Scalability. The system should be able to handle high volumes of traffic.

  • High availability. Users should still be able to use the system when some servers are offline, slowed down, or have unexpected network errors.

Back of the envelope estimation

  • Assume the application has 50 million signed up users and 10 million DAU.

  • Users get 10 GB free space.

  • Assume users upload 2 files per day. The average file size is 500 KB.

  • 1:1 read to write ratio.

  • Total space allocated: 50 million * 10 GB = 500 Petabyte

  • QPS for upload API: 10 million * 2 uploads / 24 hours / 3600 seconds = ~ 240

  • Peak QPS = QPS * 2 = 480

Finished reading?

Mark it complete to track your progress.