Types of System Design Interview Questions

In this chapter, we'll look at the main types of system design interview questions, what interviewers expect from each, and how to identify the focus of a question so you can spend your time on the areas that matter most.

Most system design interviews follow a similar format. You're given a short problem statement and around 45 minutes to work through a design. However, different questions can test very different skills.

For example, "Design Instagram" and "Design a Rate Limiter" are both system design questions, but they require different approaches.

If you approach both questions the same way, you might waste time discussing obvious requirements for a rate limiter or dive too deep into one part of Instagram before explaining the overall architecture.

That's why it's important to recognize the type of question you're being asked and adjust your approach accordingly.

The most common type of system design interview question is product design, where you're asked to design a user-facing application like Twitter, Instagram, YouTube, Uber, or Ticketmaster.

These applications have many features, and you can't cover all of them in a single interview, so the first step is to narrow down the scope.

For example, Twitter supports posting tweets, following users, viewing timelines, searching, notifications, and direct messages. In an interview, you might agree to focus on just three features:

Once the scope is clear, you need to explain how these features work end to end. How are tweets stored? How do they appear in followers' timelines? What happens when someone opens their home feed?

From there, the discussion usually moves toward scalability and design trade-offs. Should you generate timelines when tweets are posted or when users open their feeds? What happens when someone with millions of followers posts a tweet?

These questions test your ability to prioritize requirements, design the overall architecture, and explain how different components work together to support the application.

Infrastructure design questions focus on building components that other services depend on. Common examples include rate limiters, distributed caches, key-value stores, message queues, job schedulers, and unique ID generators.

Unlike product design questions, the core requirements are usually straightforward. For example, a key-value store needs to support operations like get and put. A rate limiter decides whether an incoming request should be allowed or rejected.

The real challenge is designing these components to work efficiently and reliably at scale. For a key-value store, you'll need to explain:

Performance and availability are especially important because other services depend on these components. For example, a rate limiter might need to check every incoming request, so it must introduce very little latency.

You also need to consider what happens if the rate limiter becomes unavailable. Should requests be allowed through or rejected?

The diagram is small, but the depth is in the details: where the counters live, how fast each check is, and what the system does when the shared store is slow or down.

These questions are particularly common in senior-level and infrastructure-focused interviews, where interviewers expect a deeper understanding of distributed systems and their trade-offs.

Another type of system design question focuses on how clients interact with the backend. Depending on the interview format, these questions may be called product architecture or API design.

They can sound similar to broader system design questions, so it's important to clarify what the interviewer expects you to focus on.

In these interviews, you'll spend more time designing API endpoints, defining request and response formats, and choosing an appropriate data model. Scalability and reliability still matter, but the main emphasis is on how clients interact with the system.

For example, suppose you're asked to design a comment system for a news website. You'd start by defining how users can post comments, reply to existing comments, and retrieve comments for an article.

Then you'd discuss pagination, nested replies, and how new comments appear without requiring users to refresh the page.

You should also consider how these APIs behave in practice. For example, if new comments arrive while someone is reading a news article, page-number pagination might cause comments to appear twice or get skipped as their positions change.

Cursor-based pagination with a stable ordering can help avoid this by fetching the next set of comments based on a specific position rather than a page number.

Data processing questions focus on systems that collect and process large amounts of data. Common examples include ad click aggregators, systems that identify the top-K trending videos, monitoring systems, and log collection pipelines.

These systems often need to handle a continuous stream of events. For example, an ad click aggregator might receive tens of thousands of clicks every second. If advertisers are billed based on these counts, even small processing errors can lead to incorrect charges.

This brings up several important design decisions:

Technologies like Kafka, Flink, and Spark often come up in these discussions, but what's more important is explaining why you need them and what role each one plays.

The interviewer wants to see whether you can design a complete data pipeline, from collecting and processing events to storing and querying the results, while maintaining the required accuracy even when failures occur.

The four categories we've covered describe the general focus of different system design interviews. But we can also group questions based on the technical challenges they involve.

This is useful because many applications share similar design problems, even if they serve different purposes:

The specific requirements may differ, but the underlying challenges are often similar. Understanding these common patterns gives you a useful starting point when approaching a new problem. Most of the practice problems later in this course are organized around these common design challenges.

Let's look at each of these groups and the key decisions you'll need to make for each one.

The first group is real-time communication systems, such as chat applications, live comments, and collaborative editors. These systems need to deliver updates to connected users with very little delay.

To support this, you'll often use persistent connections like WebSockets and need a way to route messages to the servers maintaining each user's connection.

Depending on the application, you'll also need to handle offline users, message ordering, and delivery receipts. For collaborative editors, there's an additional challenge of handling changes made by multiple users at the same time.

Another group is location-based systems, such as Uber, Yelp, or a nearby-friends feature. These systems need to efficiently find people or places near a given location.

Traditional B-tree indexes on latitude and longitude aren't ideal for these searches. Instead, we often use spatial indexing techniques like geohashes or quadtrees to narrow down the search area.

Ride-sharing applications introduce another challenge because drivers are constantly moving. Their locations might be updated every few seconds, so you'll need to explain how these updates are stored and how quickly they become available when someone searches for nearby drivers.

Social feeds, like those on Twitter or Instagram, are typically read-heavy. Users check their feeds much more often than they create posts.

The main challenge is generating a personalized feed quickly. This leads to decisions around caching, precomputing timelines, and handling accounts with millions of followers.

Media platforms, such as YouTube or Netflix, focus on processing and delivering large amounts of content.

For example, when a video is uploaded, it needs to be processed into different resolutions and formats before being delivered to viewers. You'll need to discuss reliable uploads, video processing pipelines, object storage, and CDNs.

Another important concept is adaptive bitrate streaming, which allows the video player to adjust the quality based on the viewer's network conditions.

Search systems have a different focus. They need to organize and index data so users can find relevant results quickly.

For text search, we typically use inverted indexes, which map words to the documents containing them. For autocomplete suggestions, we might use prefix indexes or tries.

In both cases, you'll also need to explain how new content gets indexed and how quickly it becomes searchable.

Systems that handle money, inventory, or reservations need to pay special attention to data consistency and correctness. Common examples include movie ticket booking systems, hotel booking systems, e-commerce checkout, and payment systems.

For example, if two users try to book the last available ticket at the same time, only one should succeed. Similarly, if a payment request times out and the client retries, the user shouldn't be charged twice.

The important thing is understanding which operations require strong consistency. Not every part of the system needs the same guarantees. For example, browsing events or viewing event details can still use eventual consistency, with caches and read replicas to improve performance.

In an interview, you should be able to identify which operations require stronger consistency guarantees, explain how you'd enforce them, and justify why those guarantees are necessary.

Even within the same category, a system design question can go in different directions.

For example, if you're asked to design YouTube:

That's why it's important to clarify the main requirements early and agree on which features to focus on.

The requirements can also change as the interview progresses. After you've explained your initial design, the interviewer might ask, "What if traffic increases by 10 times?" or "What if users need to see updates in real time?" These follow-up questions test whether you understand the trade-offs behind your decisions and can adapt your design when requirements change.

You might also be asked to design a product you're not familiar with. In that case, start by clarifying what the system needs to do, and then identify the underlying technical challenges, such as real-time communication, location-based search, large file storage, event processing, or data consistency.

Once you recognize these familiar patterns, you can apply what you already know, even if you've never worked with that particular product before.

Before you start preparing, it's important to understand the type of interview you'll be attending. Some interview rounds may sound similar, but they test different skills.

Low-level design

Low-level design, also called object-oriented design, focuses on code structure and behavior. If you're asked to design a parking lot, you'll typically define classes, interfaces, and their relationships, and may also need to write working code. Most of the discussion stays at the application level rather than the overall system architecture.

Machine learning system design

Machine learning system design focuses on systems like recommendation engines and spam classifiers. Along with the infrastructure needed to serve these systems, you'll discuss data collection, feature engineering, model training, and evaluation.

Project deep dive

Another common format is a project deep dive, where the interviewer asks you to explain a system you've worked on. You'll need to discuss the design decisions you made, the challenges you faced, how the system performed in practice, and what you would do differently.

If you're unsure about the interview format, ask your recruiter what the round will cover. This will help you focus your preparation on the skills you'll actually be evaluated on.

Different types of system design questions require different approaches.

Before your interview, make sure you understand the format used by the company you're interviewing with, so you can prepare accordingly.

In the next chapter, we'll look at how interviewers' expectations change with your experience level, from entry-level to staff.