This system design interview guide was assembled with the help of software engineers, technical program managers, and engineering managers at Google, Meta, and Amazon.
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.
If you're interviewing for a technical role, you're bound to come across system design questions at FAANG/MAANG companies and many startups.
You may be intimidated, given the ambiguous nature of the questions, which vary from company to company. But luckily, the general format is predictable.
Your hiring manager will evaluate the way you go about solving technical problems.
They will look at your 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.
Table of Contents
- Top 30 System Design Interview Questions
- What is System Design?
- Example Question and Answer: Design a Web Crawler
- Example Question and Answer: Design YouTube
- Example Question and Answer: Design Reddit
- Example Question and Answer: Design Twitter
- How to Answer System Design Interview Questions
- System Design vs. Software Engineering Interviews
- System Design Interview Tips
- Frequently Asked Questions
- Additional System Design Interview Prep
Most Commonly Asked System Design Interview Questions
These questions were recently asked at tech companies and reported by our users in our interview questions database.
- Design Instagram.
- How would you build TinyURL?
- Design a reservation and payment system for a parking garage.
- How would you design an AI data product?
- Design TikTok.
- Design Prime Video.
- Design a Typeahead box for a search engine.
- Design Amazon's Kindle payment system.
- Design YouTube.
- Design a web crawler.
- Design a visual landmark recognition system.
- When Should You Use Http vs. Https?
- Break a Monolith into Microservices.
- How would you design a relational schema for a calendar application?
- Design a metrics and logging service.
- If you visit a Bitly URL in your web browser, what happens behind the scenes?
- Design a vending machine.
- Design Reddit's homepage.
- Design Zillow.
- Design Airbnb Search.
- Design Uber.
- How does Alexa process voice commands?
- Design a service that supports uploading and tagging images to a travel site.
- Design Facebook Messenger.
- 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?
- Design a Tic Tac Toe game that I can play with remote opponents.
- Walk me through the technical architecture needed to build a mobile alarm clock app.
- Design APIs for Facebook live commenting.
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.
System design interviews get a high-level understanding of how you think about building reliable systems for customers and companies.
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 the 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 requests and mistakes while performing according to the specified requirements. Reliability also means that unauthorized access to the system can be thwarted.
- Availability: This term describes 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 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.
Example Question 1: Design a Web Crawler
Being asked to design a web crawler is incredibly common system design interview question.
First and foremost, a candidate will need to have a thorough understanding of the Internet's technical details.
They'll need a conceptual understanding as well. This system design interview question gets at the root of both. So, how can you answer it?
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. Ask questions like:
- Are we prioritizing certain web pages 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 web pages? Should we assume they all contain HTML, for example? Should our crawler account for other media types beyond this?
Remember, your system design interview should be a place you feel comfortable asking questions of your interviewer as well. Get their pulse on the direction of your answers.
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 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 crawler to "visit" a site, it simply makes an HTTP request to the URL while loading the page contents.
Once the crawler has crawled the page and scanned its contents, it needs to extract any other links that it finds on the page.
This can be handled relatively easily, thanks to many 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 you'll need access to a massive amount of storage space to build a crawler capable of crawling the entire web.
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.
Now, that's conservatively speaking. Today, there are more than a billion pages on the modern web.
If each page was 200 KB, that would be 0.2 petabytes of data. So long story short, our crawler will need a lot of space. However, deciding on our storage system depends on how we plan to use our web crawler.
For instance, let's say we were building our web crawler to download and store web content to archive offline.
In this case, we'd need to compress and store our crawled contents, and we could do so with cloud storage.
However, suppose we were building our web crawler for searches in real-time. In that case, we may find that a distributed system would be better served for search and querying.
Regardless, the amount of data necessary makes it impractical to store in memory. So 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 or "extract, transform, load."
Make Use of Parallelization
Finally, we can use parallelization to ensure that the web crawler is efficient and reliable.
This 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 use all three to achieve the best result.
Example Question 2: Design YouTube
"How would you design a large-scale, distributed system and video-sharing platform such as YouTube?"
Note that an interviewer asking 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 components 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 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 and middle-tier services alongside a database. iOS apps, on the other hand, would be better served with an MVC pattern (model-view-controller).
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 delivery are 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 in your system design interview. Your interviewer wants to know how you ask questions and think through problems for real-world systems.
Example Question 3: Design Reddit
"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 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 system design interview 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 mobile and web users, or just one or the other?
- Will the images be uploaded to the system itself, or will they be linked to another hosting service?
- Are there any necessary performance-related features that would influence our system design and require load balancing?
Suppose 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.
Essential 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 uploaded images.
In this particular case, a relational database is the most appropriate choice. Again, 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 we will use for our system. These servers must handle the system data and 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. Load balancing is a crucial ingredient in ensuring a system can scale reliably.
To learn more about load balancing, check out our resource on How to Cover Load Balancing in a System Design Interview.
Finally, we will define each part of our system. Once outlined, we can define each part of our system in greater detail.
Here, 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 4: Design Twitter
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 establishing 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. Finally, we must remember 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.
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. Instead, interviewers use these types of system design interview 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! Instead, 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 compels the interviewee to clearly define the problem space before jumping 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 the interviewer and interviewee. Be sure to clearly define the problem space with your interviewer. You'll want to understand if you're focused on building distributed systems, what your traffic control system will look like, and how other software engineers or team members may
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. They hear a system design interview question they're familiar with and jump straight to the solution.
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, 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 time to dive 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 proceeding, always explain to your interviewer why you believe these components are the most important for your system.
It could be that the interviewer may feel another component or constraint is more important. Checking in with them before diving deeper gives them a 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. This is because 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 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 also ask you questions about aspects of your design here.
System Design vs. Software Engineering Interviews
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 could 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.
System Design Interview Tips
In the end, there are no set answers in system design interviews. In fact, even the authors of our favorite system design books have various thoughts on distributed systems.
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 to flesh out why you are making your design decisions and their respective tradeoffs.
You will need diverse knowledge and comfort with many different technologies, database systems, distributed systems, and more 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 a much broader knowledge of 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 which 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 and 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 your design decisions 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 architectural pattern, as there is no one size fits 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.
Frequently Asked Questions
These are some of the most commonly asked questions around prepping for these tough interviews.
Does Amazon ask system design interview questions?
Yes and no. Amazon asks system design questions in their engineering interviews. However, they don't ask these types of questions to freshers and recent graduates. System design questions are usually only asked in interviews for experienced positions (4-5 years of experience).
Does Google ask system design interview questions?
Yes, Google asks system design questions. They are asked during the technical phone interviews. Your initial phone screens won't have any system design elements to them. Instead, you'll be asked about algorithms and data structures. You'll encounter system design questions if you're advanced to the next interview round.
To pass the Google system design interview, we recommend focusing on your whiteboarding skills.
Are system design interviews difficult?
System design interview questions are notoriously difficult to prepare for. Unlike algorithmic questions, they don't reduce down to a handful of prescribed patterns. Instead, they require years of technical knowledge and experience to answer well.
For junior engineers, this can be tricky. Even senior developers sometimes find themselves scratching their heads trying to understand a system.
The key to doing well in these types of interviews is to use your entire knowledge base to think about scalability and reliability in your answer.
What is the difference between high-level and low-level system design?
The high-level design focuses on the problem you're trying to solve. The low-level design breaks down how you'll actually achieve it. That includes breaking down systems into their individual components and explaining the logic behind each step. System design interviews focus on both high-level and low-level design elements so that your interviewer can understand your entire thought process.
Additional System Design Interview Prep
The system design interview round can be one of the most challenging aspects of modern tech interviews. One of the best ways to prepare is by taking system design interview courses, such as this one.
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 the following:
💬 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.