This system design interview guide was assembled with the help of software engineers, technical program managers, and engineering managers at Google, Meta, and Amazon.
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.
These questions were recently asked at tech companies and reported by our users in our interview questions database.
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.
These 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:
Before we get into the sample system design questions, we should first cover the structure of system design interviews.
However, if you want to jump right into our sample interview questions, click here.
Individual system design interviews may, of course, differ depending on the organization. You can presume three things about your interview.
Most times, your interviewer will give you 45 - 60 minutes to answer a system design question, such as “Design a rate limiter.”
It’s a good idea to focus on the kinds of issues that the company is currently experiencing, as they often ask candidates to design systems to solve these problems.
When answering, you’ll likely use the whiteboard or an online tool such as Google Drawings to outline your design.
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?
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:
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.
Every web crawling application must be able to do the following:
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.
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."
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:
You're not limited here to just one choice. If anything, it'd be best to use all three to achieve the best result.
View the full answer to how to "Design YouTube" here.
"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, and any video streaming service for that matter, is obviously an incredibly complex system. Keep it simple. These system design questions are ultimately looking to see if you can:
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.
View the full answer to how to "Design Reddit" here.
"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:
The question would come with the following constraint:
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:
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.
View the full answer to how to "Design Twitter" here.
The requirements for Twitter would be something like the following:
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.
Web protocols are the rules and standards that govern how information is transmitted over the internet. Several noteworthy web protocols may come up during your system design interview:
Load balancing is a technique used to distribute incoming traffic across multiple servers or resources to ensure that no single server becomes overloaded and unable to handle the traffic.
Load balancing is something to understand well as it allows a system to scale horizontally, meaning that it can handle a larger workload by adding more servers or resources rather than relying on a single, powerful server.
Many modern technical systems rely on load balancers. Therefore, they come up frequently in system design interviews.
Content Delivery Networks (CDNs) are a distributed network of servers that deliver content, such as web pages, web documents, images, and videos, to users based on their geographic location. A content delivery network is used to improve the performance and availability of a website or web-based application by reducing the distance that data has to travel between the server and the user.
CDNs replicate content across a network of servers located in strategic locations around the world. When a user requests content, the CDN determines the user’s location and subsequently directs the request to the server that is closest to the user. In doing so, CDNs reduce latency and improve the overall user experience.
The CAP theorem is a principle relating to databases that state a distributed database system cannot guarantee all three of the following properties simultaneously:
Instead, a system must choose between consistency and availability in the face of network partitions. This means that a system can either prioritize consistency and sacrifice some availability or prioritize availability and sacrifice some consistency.
Databases are a critical component of technical systems and will inevitably be involved in your system design interviews. A database is a structured collection of data that is stored and accessed electronically.
There are many kinds of databases you can choose from when designing systems:
It is important to understand the various databases and how they can store and retrieve data in the system you’re designing. This includes understanding the trade-offs between different database technologies and how to choose the best database for a particular application.
Caching is a technique used to store frequently accessed data in a temporary storage location, typically in memory, to improve the performance of a system. Caching is commonly used in system design because it can significantly improve the speed at which a system can retrieve data.
There are many types of caching that are used often in system design:
System design is a broad topic, with many important topics. Learn more about everything you need to know for your system design interview here.
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.
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:
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:
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.
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:
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 interview questions are similar to coding questions in that they are fundamentally technical. However, they differ in a few crucial ways:
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.
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.
These are some of the most commonly asked questions around prepping for these tough interviews.
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).
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.
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.
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.
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.
Exponent is the fastest-growing tech interview prep platform. Get free interview guides, insider tips, and courses.Create your free account