Tackling the System Design Interview or How to Design Instagram from the Ground Up in 45 Minutes

One of these interview questions is not like the other:

1. “What is your greatest strength?”
2. “Tell me about a time when you didn’t get along with a co-worker, and how you resolved that conflict.”
3. “Can you design an existing multi-billion dollar company’s social media platform before lunch?”

Did you catch it?

The system design interview is becoming more and more common for software engineering roles, and they can certainly be intimidating at first. How would you even begin to design Twitter, Facebook, or Instagram, much less in 45 minutes?

Think about it like this- the system design interview is an opportunity to collaborate with a fellow engineer on modeling a large-scale application, and tackle the subsequent challenges together. Only, the engineer you work with just so happens to be hiring.

There are three main points you should focus on:

1. The scope of the problem
2. How to sketch the design
3. Identify and address bottlenecks that arise in your system

WAIT- I'M THE ONE BEING INTERVIEWED. WHY AM I ASKING THE QUESTION?

The trick to nailing the SDI is to become comfortable asking clarifying questions related to these three points. Sure, the interviewer will ask you questions about the overall application, but you’ll find that these are mostly open-ended, and designed to make you think critically about certain design choices. It is your job as the engineer to get as much information as you can throughout the process.

Rarely is there ever one correct answer, so it’s important to ask a lot of these clarifying questions early on. So how can we make sure we’re asking substantive questions? Let’s break it down into more manageable chunks by building a real-world example together: Instagram.

1. SCOPING THE PROBLEM.

Scope refers to the extent of the system. When identifying the scope, ask yourself:

• What is the service we are designing?
• Who are its users?
• What are the basic features, and what are the stretch features?

The interviewer is expecting you to make a few assumptions. After all, you probably have some familiarity with the platform you'll be designing. But you probably don't know the exact number of users a particular application may have. Ask yourself the above questions out loud, and make a few educated guesses, so the interviewer can follow along with your thought process.

Let's answer these questions about Instagram, for example. Instagram is a social networking service that allows users to upload content, connect with other users, and interact with that content. It has a colossal user base, including celebrities, politicians, and major athletes. However, the average user is between the ages of 18 and 35. Our version of Instagram should be able to upload photos, delete photos, follow users, and delete users. Stretch features include search functionality, commenting on photos, etc.

ESTIMATING THE SCALE

The scale is the expected user base of our application, and ability to grow with more users. When estimating scale, it is important to note the difference between assumptions and clarified answers. The biggest questions here are:

• How much storage will we need?
• What is the network bandwidth we’ll be expecting?

To estimate storage, several factors come into play. You have to take into consideration:

• The total users
• How many of those would be considered daily active users
• The amount of data each user creates

This is a perfect time to ask some clarifying questions- start with your best estimate of the total user base, and check in with the interviewer to see if your assumption is fair. It’s important to be as accurate as possible, but the interviewer isn’t expecting you to know the specific data points of any specific application. That conversation MIGHT go something like this:

Let’s assume that Instagram has 1 million daily active users, and 500 million total users. These users upload an average of 23 photos every second, adding up to 2 million unique posts per day. If each photo is roughly 200KB, then the total storage for one day would be about 400GB. Over the course of a year, we would need to store 146TB of data.

Whew! That's a lot of information. Take your time, and be sure to mark the important information on the whiteboard.

Give yourself about a quarter of the whiteboard to write important data info.

2. SKETCHING THE DESIGN

Now that we’ve focused our scope and hammered out our scale, we can begin our mock-up, which typically consists of three things: a basic user interface that gives us a visual of the user-facing application, data models that will highlight how our data is stored, and overall design of how each component in our system interacts with each other.

MOCKING UP A BASIC UI

This can be a (very) rough sketch. Don’t worry about how the UI looks- remember, you have a limited amount of time to present an entire system. As long as all of the components a user would need to interact with your application are there, it doesn’t matter if every line isn’t perfectly straight.

A basic Instagram UI should include:

1.  A main feed, which contains smaller feed components.
2.  A user profile with the ability to upload photos.

DEFINING THE DATA MODEL

Defining the data model after sketching out the basic UI will help you clarify how data flows through components of the system through the rest of the interview. This will also aid in data partitioning and management.

For our Instagram example, we could potentially store all of our data in either a relational or non-relational database. This is a great opportunity to show that you know the advantages and disadvantages of storing data in either option! A non-relational database offers a faster look-up time, and the main focus of our application would be photo retrieval.

On the flip-side, since we have to keep track of a specific user’s photographs, followers, who they’re following, and potentially private user information, perhaps it would make more sense to store our information in a relational database connected with several join tables.

For our version of Instagram, let’s store information in a relational database made of three tables: one for user information, one for photo information, and one for user follower information.

DEFINING YOUR APIS

Your APIs essentially determine the functionality of your system. Start by defining an API for each of the MVP features you want your application to contain. Each API should also contain the exact data required for such a call to be completed.

For a basic Instagram SDI, the major APIs would include:

• /uploadPhoto (photoID, userID, caption, etc.)
• /deletePhoto (photoID, userID, etc.)
• /followUser (userID1, userID2)
• /unfollowUser (userID1, userID2)

HIGH-LEVEL AND DETAILED DESIGN

In general, it is better to start with high-level components before moving on to sketching out a detailed system. Think of this as sketching out your MVP- you have to have your User Interface, Database Model, and APIs all detailed. Now it is time to map out how everything should work in congruence with each other. Start by mapping out the core components of your system.

The most important functions to include would be the ability to upload photos from a user, search for/view photos from other users, and store photos. Once we’ve mapped out the flow of data from UI to backend, we can start to ask ourselves more complex questions:

• How do we handle especially active users?
• Since we’re storing such large amounts of data, what would be the best way to partition it?
• Where can we introduce caching and load balancing to increase the performance of our application?

3. IDENTIFYING AND ADDRESSING BOTTLENECKS

For every obstacle you come across when designing your application, there will invariably be more than one solution. And that’s okay! This is another opportunity to speak to the advantages and disadvantages of certain technologies over others. Even if the interviewer doesn’t explicitly ask for your reasoning, be ready to answer questions like:

• What type of database would you use, and why? (What is more important to the user- speak of data being returned? Security of personal information?)
• How are we monitoring and maintaining the performance of our system?
• Do we have enough copies of our data that losing a few servers would have minimal impact?
• Would an error in one of our services affect the entire system?

A FEW QUICK TIPS

Remember, at the end of the day, this should feel like a conversation with a fellow engineer, as well as an opportunity to pitch ideas and solutions to common problems. Here are a few tips to make the process go as smoothly as possible:

• The 80-20 rule. Try to speak for the majority of the time, but don’t hesitate to ask your interviewer for insight, or clarification on specifics requirements.
• All of your ideas should be represented in your whiteboarding. Even if they aren’t fully flushed out our insanely detailed, having a complete mock-up on the whiteboard will give you a visual to fall back on if you find yourself stuck.
• Be honest. If you’ve never used a certain technology or are unfamiliar with a specific solution, say so- this could be a great learning opportunity. An interviewer is more likely to be impressed with someone who is honest, and shows confidence and a willingness to learn.
• Practice is key! There is no substitute for actually designing systems on your own and with your peers to help you prepare for actual SDIs. Make a list of your favorite applications (Twitter, Dark Sky, bit.ly, etc), and mock up a system design for them.

Hopefully, this helps make the system design interview seem a little less daunting. Good luck!