Sneak Peek: The three most common system design questions:
- Design Instagram. Watch an answer to this question here.
- How would you build TinyURL? Watch answer here.
- Design YouTube. Watch a sample answer to this question here.
The system design interview is critical in the hiring process for many different roles.
Software engineers (SWE), technical program managers (TPM), engineering managers (EMs) and even product managers all go through a system design interview.
If you’re interviewing for a technical role, you’re bound to come across this round at virtually all FAANG companies and many startups.
You may be intimidated given the ambiguous nature of the questions, which vary from company to company. Luckily, the general format is predictable.
Your hiring manager will evaluate the way you go about solving technical problems.
They will look at your logical decision-making in the face of uncertainty, your confidence in tackling risks, your capacity to pivot in light of new information, and many other factors.
This guide is designed to help you nail your system design interview. In it, you'll learn:
- What is System Design?
- Most Common System Design Interview Questions
- How to Answer System Design Interview Questions
- Example Question and Answer: Design YouTube
- Example Question and Answer: Design Reddit
- Example Question and Answer: Design Twitter
- Example Question and Answer: Build a Web Crawler
- System Design Interview Tips
- Additional System Design Interview Prep
Complete System Design Interview Prep Course
Learn how to answer system design questions with in-depth video examples and fundamental concepts.
What Is System Design?
System design in this context means defining the architecture, product design, modules, interfaces, and data for a system according to given requirements.
The purpose of system design is to architect a system that can effectively support the functionality of a product or service.
A system can be designed well across multiple dimensions in system design. These dimensions are:
- Scalability: A solid system must be scalable. This means that it can handle additional load and will operate with efficiency while doing so.
- Reliability: Systems must also be reliable. They perform the way they are supposed to. Systems need to handle user mistakes while performing according to the specified requirements. Reliability also means that unauthorized access to the system can be thwarted.
- Availability: This is the term used to describe whether or not a system can perform its intended function. Availability can be measured in time (its uptime, for example). The availability of a system is related to its reliability but, make no mistake, it is not the same thing. However, if a system is reliable, it is also available, not but necessarily vice versa.
- Efficiency: A well-designed system is an efficient system. Efficiency means the system performs its functions quickly and reliably. Efficiency is measured with metrics like latency, response time, and bandwidth.
- Maintainability: A well-designed system must also be easy to maintain over time. This means that the system must also be designed with new engineers in mind. It must be simple enough for them to understand quickly and modify in unanticipated ways.
Most Common System Design Interview Questions
System design interview questions can be one of the most challenging aspects of tech interviews for many different roles.
System design interview questions are similar to coding questions in that they are fundamentally technical. However, they differ in a few crucial ways:
- System design questions are vague on purpose: Whereas coding questions must be clear to the candidate to answer effectively, system design questions are just the opposite. Here, the interviewer is less concerned about getting a correct answer, per se. Instead, they are interested in the direction you choose to answer the question.
- System design interview questions do not have straightforward answers: As we just mentioned, interviewers won't be looking for the "right" answer to their questions. This is because there is none! While it's true both good and bad designs are possible, your interviewer is evaluating the design choices you make. They will assess how you choose between tradeoffs along with your thought process more generally.
- System design interviews are two-way discussions: The most unique aspect of system design interviews is the two-way nature between candidate and interview. During your answer, you will ideally work with your hiring manager along the way. This means you should always be sure to ask plenty of clarifying questions throughout your interview. Even if your recruiter answered questions about the job, you can ask the same questions to your hiring manager to show you're engaged with the position.
Of course you shouldn’t simply copy our answers here—any competent hiring manager will be able to spot a formulaic response from a mile away. However, these samples could help you deduce the best way to go about answering these questions.
Example Question: Design YouTube
In this mock system design interview, Hozefa (Wealthfront EM) answers the interview question, "Design YouTube or a YouTube like service."
"How would you design a large-scale, geo-distributed video-sharing platform such as YouTube?"
Note that such a question is not expecting a truly complete answer. Youtube today is obviously an incredibly complex system. Keep it simple. These system design questions are ultimately looking to see if you can:
- Pull together a small set of requirements from an ambiguous question.
- Define a minimum viable product (MVP) according to these basic requirements.
- Produce a high-level architecture with all the numerous components that are necessary to implement your design.
- Discuss the tradeoffs between components and algorithms, and explain your choices.
- Provide an additional level of detail on any given component or design decision depending on where your interviewer wants to deep-dive.
Design YouTube Interview Question: Our Answer
First, clarify the requirements with your interviewer (a common and recommended first step for any system design question). From there, you need to decide which of these are most important and should take priority in your design.
Next, outline your problem space to some well-established or familiar architectures that are appropriate for the requirements.
For instance, many system design questions (such as this one) can be outlined using a client-server pattern.
This means that the design includes a user-facing client, middle-tier services alongside a database. iOS apps, on the other hand, would be better served with an MVC pattern (model-view-controller).
Now, you will need to structure your answer with an outline, or system diagram, of the high-level components that will make up the architecture pattern you’ve chosen.
From there, elaborate and expand on each of the components, making sure to describe how they’re connected and how they communicate with each other.
It’s helpful to start with the component closest to the user and move backward from there. This will help show your hiring manager that your design process and deliver is methodical and user-centric
Always be sure to explain each of your design decisions as you answer the question, and check in frequently with your interviewer.
Communication is being tested as well; don’t be afraid to engage.
Example Question: Design Reddit
Imagine you're the lead engineer responsible for building Reddit from the ground up.
"Let's pretend that you are the lead engineer tasked with building a platform like Reddit from scratch.”
Assume you’re given the following requirements:
- Users can make posts in different forums (subreddits),
- Users can include images in their posts,
- Users can upvote or downvote posts they like or dislike,
- Users can leave comments on posts,
- The system has a news feed of posts sorted by both ranking and recency of posts.
The question would come with the following constraint:
- The system must be able to support large volumes of users viewing and posting content simultaneously.
Design Reddit Interview Question: Our Answer
There's no denying, this is a broad system design question. We will follow a similar approach as we did for the previous question.
First, we will define the problem space. This, again, means clarifying the requirements. In this sample question, the interviewer gave you a concrete list of necessary features.
Still, you should first dig deeper into the requirements for additional clarification and detail. For instance, you can ask questions like:
- Does our system need to support users on mobile and the web, or just one or the other?
- Will the images be uploaded to the system itself, or will they be links to another hosting service?
- Are there any necessary performance-related features that would influence our system design?
Let's imagine your interviewer stated you only need to be concerned with web users.
We also want the images to be uploaded directly to our system and need all the system's content to load as quickly as possible for all users, no matter where they may be located.
Next, we will outline the high-level design. Now, we need to choose a few primary components of our Reddit system.
Based on what we know about the feature requirements, we know these components will need to allow users to view, post, rank, and comment on other posts.
Important components include databases, user interfaces, servers, and more. For this question, we’ll begin with the database and move from there. The database will need to store all the user data regarding posts, upvotes/downvotes, and the uploaded images.
In this particular case, a relational database is the most appropriate choice. This is because of the relational nature of our data (one user will have several posts, which, themselves, will contain many upvotes/downvotes, and comments).
As such, it would make the most sense to use a SQL database because of its natural efficiency with relational data and simplicity.
From here, we need to define the application servers that we will use for our system. These servers will need to handle the system data, authenticate users, along with many other operations.
Because our interviewer mentioned our system needs to work at massive scales, we will need to use many server instances.
As a result, a load balancer should be implemented, as well, to manage the traffic across the server instances.
Finally, we will define each part of our system. Once outlined, we can define each part of our system in greater detail.
It is here where we elaborate on our design decisions and the tradeoffs that come alongside them. Unfortunately, you may not have the time to dig deep into every single aspect of your system.
Nevertheless, you should be capable of diving deep into any of them, if necessary.
Example Question: Design Twitter
How would you build a Twitter clone that sends tweets, follows users, and scales in an efficient way?
The requirements for Twitter would be something like the following:
- Sending tweets
- Following other users
- Tweet feed/newsfeed
- System is scalable
- Loads quickly
- System is reliable
Design Twitter Interview Question: Our Answer
After you establish the requirements, you can begin to outline your design of the Twitter API. That would look something like this:
We'll start by outlining important endpoints for the API design. These include:
Then, we can begin sketching out the architecture to support these features. We can start with the user who makes a request to the server.
To accommodate the scalability requirement, we can put several API servers behind a load balancer to help route larger traffic volumes.
Now, we need to include a database to store our tweets. We have to keep in mind that the API we design needs to be scalable.
Therefore, we need to choose a database that is easy to shard and a data model that can handle a large number of reads and writes on the part of the API servers.
When it comes to making this application scaleable, we can have one of our API servers read from a separate cache for our newsfeed. In doing so, we should also use a feed service to refresh our feed cache regularly.
30 Most Common System Design Interview Questions
- Design Instagram. Watch an answer to this question here.
- How would you build TinyURL? Watch our co-founder, Jacob, answer this question here.
- Design a reservation and payment system for a parking garage. Watch an expert answer to this question here.
- How would you design an AI data product? Watch a sample answer to this question here.
- Design Twitter's API. Watch our co-founders take a crack at this question here.
- How would you design a relational schema for a calendar application? Watch an expert answer to this question here.
- Design a typeahead box for a search engine. Take a look at our sample answer to this question here.
- Design a metrics and logging service. Watch an answer to this question here.
- Design YouTube. Watch a sample answer to this question here.
- Design a web crawler. Watch an answer to this question here.
- If you visit a Bitly URL in your web browser, what happens behind the scenes?
- Design a visual landmark recognition system.
- Design a service that supports uploading and tagging images to a travel site.
- Design a cache controller.
- Design Amazon's Kindle payment system.
- What does MTBF mean and why is it needed?
- How would you design end-to-end user onboarding for an app?
- How long does it take to send a signal from one computer to all other computers?
- Build a micro version of the Twitter Timeline.
- Design a Tic Tac Toe game that I can play with remote opponents.
- Walk me through the technical architecture you would need to build a mobile alarm clock app.
- Design APIs for Facebook live commenting.
- Design a vending machine.
- Design Reddit's homepage.
- Design Zillow.
- Design Slack.
- Design Airbnb Search.
- Design Uber.
- How does Alexa process voice commands?
- Design Prime Video.
If you need help answering these questions or want to know how to prepare in a crunch, check out Exponent's Tips for System Design Questions.
How to Answer System Design Interview Questions
First and foremost, the system design interview is designed to evaluate your capability to produce technical solutions to abstract problems. As you can probably already tell, system design interview questions are meant to simulate the real-world problems candidates would tackle in their roles.
As such, they're not designed with a specific correct answer, nor will hiring managers be looking for one. Interviewers use these questions to evaluate how you think and approach solving complex technical problems.
You must explain the various options or paths a potential solution can take, along with the tradeoffs and drawbacks of each.
Believe it or not, system design interview rounds are usually incredibly influential on which level you are hired if you receive an offer.
Despite how influential these interview questions are, don't be nervous! Use this framework to ensure you answer the question as effectively as possible, both in practice and real life.
Step 1: Define the problem
System design interview questions, by nature, are vague or abstract. This puts the impetus on the interviewee to clearly define the problem space before the jump into the potential solutions.
The first step is asking clarifying questions to tease out all the constraints your design will account for. Remember that system design interviews are meant to be two-way dialogues between interviewer and interviewee. Be sure to clearly define the problem space with your interviewer.
You may have misunderstood or missed a necessary element. However, this first step allows the interviewer to redirect you if necessary.
If you're looking for some examples of compelling clarifying questions, look no further:
- What are the features that we need to design for this system?
- What is the desired scale that this system will need to handle?
- What are the edge cases we need to consider, if any, in our design?
- What kind of system architecture should we develop to make it easier for other developers later on?
Step 2: Design high-level
After you've clarified and defined the problem space, start to design your system from a high-level first. You should do so for every piece and component of your system.
Many candidates mistakenly dive deep into details before providing a sufficient overview of their design. Doing so runs the risk of running out of time before you've managed to flesh out the whole system. As a rule of thumb, be sure to stick to a Broad, then Deep interview framework.
Some high-level considerations to remember during your system design interview:
- What will the coding framework of choice be, if any?
- What type of database is necessary for the system?
- What APIs, if any, are integral to build so the system will function properly?
- Is it best to design a monolithic system architecture or break it into several microservices?
Step 3: Dive deep
Once you've provided a broad and high-level outline of the whole system, it's now the time to diver deeper into the most critical components or constraints.
Depending upon the scale of the system in question, you may have noted that some constraints should be prioritized in your answer. There is only so much time for a candidate to answer their interview question.
As such, don't hesitate to only focus on the most critical components first. However, before doing so, always be sure to explain to your interviewer why you believe these components are the most important for your system before proceeding.
It could be that the interviewer may feel another component or constraint is more important. Checking in with them before diving deeper gives them the chance to re-direct you if this is the case.
Step 4: Find bottlenecks
Now that you've dove deeper into the details of your system design, you will now need to, once again, take a big picture view. Every technical system needs to adapt, at times, to different requirements or conditions.
This is the portion of your interview answer where you will address these concerns. Of course, the most significant changing condition is scale.
Now, very few companies are working to create products with limited success. It's the dream of every development team to build a product that becomes a sensation!
But what comes with that great success is the necessity of scalability. Otherwise, your system will be dead in the water.
You need to explain how your system can adapt and handle 10x or 100x the amount of users.
This discussion will be specific to the system you are designing. However, it's helpful if you keep some of the following benchmarks in mind:
- System handling 1,000+ users: A server and a database, the basics of any system design.
- System handling 1,000 - 10,000 users: Several servers. The use of load balancing to distribute high levels of traffic. The use of leader-follower replication to stop potential failure points.
- System handling 100,000+ users: CDNs and caches designed to lower latency and rate-limiting to avert potential abuse. It may be bested to break monolithic architecture into microservices at this point.
- System handling 1 million users: It may now be necessary to use database sharding and more advanced replication strategies such as leaderless replication to account for such large amounts of user data.
Step 5: Summarize and answer questions
Last but not least is the final step of your system design interview answer. This concluding step will consist of, once more, reviewing the system requirements and summarizing and justifying all the design decisions you made along the way.
Be sure to thoroughly explain why you think these decisions are the most prudent regarding their tradeoffs. Don't forget to mention possible alternatives you could have taken along with their tradeoffs.
It is likely your interviewer will ask you questions about aspects of your design here, as well.
Example Question: Design a Web Crawler
Being asked to design a web crawler is a commonly asked system design question.
An interviewer asking this question also accomplishes a few things at once. First and foremost, a candidate will require a thorough understanding of the technical details of how the internet works.
Not only that, they'll need a conceptual understanding, as well. This question gets at the root of both. So, how can you answer this question?
Design a Web Crawler Interview Question: Our Answer
Like any other system design question, candidates will first need to clarify and outline all the requirements of the question. Your interviewer will probably give you some general requirements, but be sure to clarify to ensure you have the full scope before you continue. When it comes to our web crawler, you can ask questions like:
- Are we prioritizing certain webpages over others while we crawl?
- What are the constraints on the data our crawler can store if any?
- What assumptions are we making about the webpages? Should we assume they all contain HTML, for example? Should our crawler account for other media types beyond this?
Outline and Implement the Crawler
Every web crawling application must be able to do the following:
- Visit websites while scanning their contents
- Find URLs from website contents
- List URLs that have yet to be crawled
- Repeat until all URLs are crawled
Now, there isn't just one way to design such an application. However, when it comes to web crawlers, there are two main approaches we can take.
These are the breadth-first or depth-first approaches. For this article, let's imagine that we go with the breadth-first. This means that our crawler will be visiting web URLs as it discovers them.
We can implement this approach by storing the URLs our crawler has yet to visit in a first-in-first-out data structure while initializing it in such a way as to ensure it only contains the initial URLs that are given.
Since we are using a first-in-first-out data structure, our crawler will only visit the URLs in the exact order that they are added to the list of URLs to crawl.
After we have our list of URLs, our crawler then needs to visit the sites and extract their contents.
For a web crawler to "visit" a site, it simply makes an HTTP request to the URL while loading the page contents.
Once the web crawler has crawled the page and scanned its contents, it needs to extract any other links that it finds on the page.
This can actually be handled rather easily thanks to many of the standard HTML libraries.
After your crawler makes its list of links, they are placed on the queue to be crawled, and our crawler can repeat its process.
Data processing and storage
It should come as no surprise that to build a web crawler capable of the entire internet, you'll need access to a massive amount of storage space.
For a rough estimate, let's do some quick math: If the average size of a crawled webpage is, let's say, 200 KB, and our web crawler was to store 1 million, or 10^6, pages, we'd need 2 terabytes worth of storage.
(10^6 * 200 * 10^3 = 200 * 10^9 = 2 * 10^11 bytes = 2 TB)
Now, that's conservatively speaking. Today, there are more than a billion pages on the modern web.
If each of these pages was 200 KB, that would be 0.2 petabytes of data. Long story short, our crawler will need a whole lot of space. Deciding on our storage system, however, is dependent on how we plan on using our web crawler.
For instance, let's say we were building our web crawler to download and store web contents to archive offline.
In this case, we'd just need to compress and store our crawled contents, and we could do so with cloud storage.
However, if we were building our web crawler for searches in real-time, we may find that a distributed database would be better served for search and querying.
Regardless, the amount of data necessary makes it impractical to store in memory. Instead, the memory will need to be continuously uploaded to a storage system. If not, the web crawler will run out of usable memory as it executes.
This is known as an "ETL" approach, standing for "extract, transform, load".
Make Use of Parallelization
Finally, we can make use of parallelization to ensure that the web crawler is efficient and reliable.
This essentially means that we design our processes to work in tandem with one another. There are a few ways to do this:
- Implement the crawler with a multi-threaded or asynchronous approach
- Run multiple instances of the crawler as different processes on a single machine
- Run multiple machines that share a job queue
You're not limited, here, to just one choice. If anything, it'd be best to make use of all three to achieve the best result.
System Design Interview Tips
In the end, there are no set answers in system design interviews. In fact, even the authors of our favorite product management books have differing opinions about how great products get built.
The hiring manager is not waiting for one specific correct answer to their questions.
They are concerned with your thought and design process. Be sure you flesh out why you are making your design decisions along with their tradeoffs.
You will need diverse knowledge and comfort with many different technologies and systems to answer these questions most effectively.
Engineers, for example, will need to elaborate deeply on the systems within their areas of expertise.
However, management roles, such as TPM, need to have a much broader range of knowledge over the systems and technologies they use.
- Define success: Don't forget to clearly define the who and the what of your solution early on when clarifying requirements. Clearly explain the nature of the problem and who the solution would be serving. Refer back to this frequently as you build your system. Doing so will help give context to the various tradeoffs of your design decisions.
- Ask clarifying questions: You wouldn’t design an implement a whole system without plenty of back-and-forth communication in the real world (we hope), so don’t do it here. When you're answering these kinds of questions, you are letting the interviewer know how you can work together to solve a specific problem.
- Answer the "why": A successful answer is always preemptively answering the "whys?" that come alongside each design decision. Clearly explain why the design decisions you make are appropriate for the given problem.
- Be thorough: Carefully explain why you make the decisions you do. Don't skip something even if it seems obvious! Your interviewer is highly invested in your thought and decision process. Explaining the obvious is a critical piece of that.
- Architectures: Don't feel like you cannot rely on or borrow from the design architectures that you are most comfortable or experienced with. So long as you can substantively explain why it is the best architecture for the required system. This doesn't mean you should try to fit every potential system design into the same architecture pattern, as there is no one size fits all in that regard.
- Think for yourself: You may feel compelled to simply ask your hiring manager or interviewer what they think are the best options or design decisions. Ultimately, this can only hurt you, as they are not interested in what they think is the best. They're investigating what you think is the best way to design a system.
Additional System Design Interview Prep
Here at Exponent, we've connected tens of thousands of job seekers in countless tech roles with expert courses and resources to best prepare them for their upcoming interviews.
If you're interested in more system design-related resources, be sure to check out:
💬 Study up on example system interview questions
📖 Read through our company-specific engineering interview guides
👯♂️ Practice your behavioral and interviewing skills with our mock interview practice tool.
👨🎓 Take our complete System Design Interview Course.