Grokking the System Design Interview by Design Gurus (z-lib.org)...

System Design Interviews: A step by step guide

A lot of software engineers struggle with system design interviews (SDIs) primarily because of three

reasons:

• The unstructured nature of SDIs, where they are asked to work on an open-ended design

problem that doesn’t have a standard answer.

• Their lack of experience in developing large scale systems.

• They did not prepare for SDIs.

Like coding interviews, candidates who haven’t put a conscious effort to prepare for SDIs, mostly

perform poorly especially at top companies like Google, Facebook, Amazon, Microsoft, etc. In these

It is always a good idea to ask questions about the exact scope of the problem we are solving. Design

questions are mostly open-ended, and they don’t have ONE correct answer, that’s why clarifying

ambiguities early in the interview becomes critical. Candidates who spend enough time to define the

end goals of the system always have a better chance to be successful in the interview. Also, since we

only have 35-40 minutes to design a (supposedly) large system, we should clarify what parts of the

system we will be focusing on.

Let’s expand this with an actual example of designing a Twitter-like service. Here are some questions

for designing Twitter that should be answered before moving on to the next steps:

• Will users of our service be able to post tweets and follow other people?

• Should we also design to create and display the user’s timeline?

Step 2: System interface definition

Define what APIs are expected from the system. This will not only establish the exact contract expected

from the system, but will also ensure if we haven’t gotten any requirements wrong. Some examples for

our Twitter-like service will be:

postTweet(user_id, tweet_data, tweet_location, user_location, timestamp, …)

generateTimeline(user_id, current_time, user_location, …)

markTweetFavorite(user_id, tweet_id, timestamp, …)

Step 3: Back-of-the-envelope estimation

It is always a good idea to estimate the scale of the system we’re going to design. This will also help

later when we will be focusing on scaling, partitioning, load balancing and caching.

Step 4: Defining data model

Defining the data model early will clarify how data will flow among different components of the

system. Later, it will guide towards data partitioning and management. The candidate should be able to

identify various entities of the system, how they will interact with each other, and different aspect of

data management like storage, transportation, encryption, etc. Here are some entities for our Twitter-

like service:

User: UserID, Name, Email, DoB, CreationData, LastLogin, etc.

Tweet: TweetID, Content, TweetLocation, NumberOfLikes, TimeStamp, etc.

UserFollowo: UserdID1, UserID2

FavoriteTweets: UserID, TweetID, TimeStamp

requests with load balancers in front of them for traffic distributions. If we’re assuming that we will

have a lot more read traffic (as compared to write), we can decide to have separate servers for handling

these scenarios. On the backend, we need an efficient database that can store all the tweets and can

support a huge number of reads. We will also need a distributed file storage system for storing photos

and videos.

Step 6: Detailed design

Dig deeper into two or three components; interviewer’s feedback should always guide us what parts of

the system need further discussion. We should be able to present different approaches, their pros and

cons, and explain why we will prefer one approach on the other. Remember there is no single answer,

the only important thing is to consider tradeoffs between different options while keeping system

our data in such a way that is optimized for scanning the latest tweets?

• How much and at which layer should we introduce cache to speed things up?

• What components need better load balancing?

Step 7: Identifying and resolving bottlenecks

Try to discuss as many bottlenecks as possible and different approaches to mitigate them.

• Is there any single point of failure in our system? What are we doing to mitigate it?

• Do we have enough replicas of the data so that if we lose a few servers we can still serve our

users?

• Similarly, do we have enough copies of different services running such that a few failures will

not cause total system shutdown?

• How are we monitoring the performance of our service? Do we get alerts whenever critical

components fail or their performance degrades?

TinyURL

Let's design a URL shortening service like TinyURL. This service will provide short aliases redirecting

to long URLs. Similar services: bit.ly, goo.gl, qlink.me, etc. Difficulty Level: Easy

1. Why do we need URL shortening?

URL shortening is used to create shorter aliases for long URLs. We call these shortened aliases “short

links.” Users are redirected to the original URL when they hit these short links. Short links save a lot of

space when displayed, printed, messaged, or tweeted. Additionally, users are less likely to mistype

shorter URLs.

For example, if we shorten this page through TinyURL:

https://www.educative.io/collection/page/5668639101419520/5649050225344512/5668600

If you haven’t used tinyurl.com before, please try creating a new shortened URL and spend some time

going through the various options their service offers. This will help you a lot in understanding this

chapter.

2. Requirements and Goals of the System

� You should always clarify requirements at the beginning of the interview. Be sure to ask

questions to find the exact scope of the system that the interviewer has in mind.

Our URL shortening system should meet the following requirements:

Functional Requirements:

1. Given a URL, our service should generate a shorter and unique alias of it. This is called a short

link.

2. When users access a short link, our service should redirect them to the original link.

3. Users should optionally be able to pick a custom short link for their URL.

4. Links will expire after a standard default timespan. Users should be able to specify the

Extended Requirements:

1. Analytics; e.g., how many times a redirection happened?

2. Our service should also be accessible through REST APIs by other services.

3. Capacity Estimation and Constraints

Our system will be read-heavy. There will be lots of redirection requests compared to new URL

shortenings. Let’s assume 100:1 ratio between read and write.

Traffic estimates: Assuming, we will have 500M new URL shortenings per month, with 100:1

read/write ratio, we can expect 50B redirections during the same period:

100 * 500M => 50B

What would be Queries Per Second (QPS) for our system? New URLs shortenings per second: