Free lesson · System Design Interviews

Types of System Design Questions

Easy13 min readsystem-designinterview-prep

Not all system design questions are created equal. The first time I realized this - truly internalized it - was during my Stripe interview loop. I had prepared by studying twenty "Design X" case studies. Design Twitter. Design YouTube. Design a URL shortener. I had diagrams memorized for each one.

Then the interviewer said: "Walk me through how you'd redesign the payment retry system for failed transactions."

That's not a "Design X" question. That's a deep-dive question about a specific subsystem. My twenty memorized architectures were useless. I needed a completely different approach - one that started with understanding the existing system, identifying the specific failure modes, and proposing targeted improvements.

This lesson is about recognizing which type of question you're facing before you start answering. Because the approach that works for "Design Twitter" will actively hurt you on "Redesign a payment retry system."

The Four Question Types

After conducting over 300 interviews and analyzing the patterns across Amazon, Google, Meta, and other companies, I've identified four distinct types of system design questions. Each tests something different, each requires a different entry point, and each has a different trap that catches unprepared candidates.

graph TD
    Q[System Design Question] --> A[Type 1:<br/>Product Design]
    Q --> B[Type 2:<br/>Infrastructure Design]
    Q --> C[Type 3:<br/>Deep Dive on<br/>Known System]
    Q --> D[Type 4:<br/>Open-Ended<br/>Greenfield]

    A --> A1["'Design Instagram'<br/>'Design a ride-sharing app'"]
    B --> B1["'Design a rate limiter'<br/>'Design a distributed cache'"]
    C --> C1["'How would you improve X?'<br/>'Walk me through Y at scale'"]
    D --> D1["'Design a system for Z<br/>that doesn't exist yet'"]

This diagram shows the four types of system design questions. Type 1 is Product Design, with examples like Design Instagram. Type 2 is Infrastructure Design, with examples like Design a Rate Limiter. Type 3 is Deep Dive on a Known System, with examples like How Would You Improve X. Type 4 is Open-Ended Greenfield, with examples like Design a System for Z That Doesn't Exist Yet.

Type 1: Product Design

Examples: "Design Twitter," "Design Instagram," "Design a food delivery app," "Design a messaging system like WhatsApp."

What it tests: Your ability to take a consumer product that the interviewer (and you) already use, and reverse-engineer the technical architecture that powers it. The interviewer knows how the product behaves. They want to see how you'd make it work.

How to approach it:

This is the most common question type, and the one most candidates prepare for. The approach is straightforward:

1. Clarify the product scope. "Design Twitter" could mean the tweet posting system, the timeline/feed system, the search system, the notification system, or the trending topics system. You can't design all of them in 45 minutes. Ask: "Which aspect should I focus on?" or propose: "I'd like to focus on the timeline feed - is that a good scope?"

2. Identify core features. List the three to five features that define the product. For Twitter's timeline: post a tweet, follow a user, view your timeline, like/retweet. Don't list fifteen features. List the essential ones that drive the architecture.

3. Estimate scale. How many users? How many daily active users? How many tweets per day? How big is each tweet? These numbers constrain your architecture. A system for 1,000 users is architecturally different from a system for 500 million users.

4. Draw the standard architecture. Clients → Load Balancer → API servers → Database/Cache/Queue. Then add the product-specific pieces.

5. Go deep on the hard parts. For Twitter, the hard part is the timeline - how do you assemble a personalized feed from the accounts a user follows? That's where the fanout pattern lives, and that's what the interviewer wants to hear you discuss.

Interview: Product Design question signals:

• The question names a real product ("Design X like Twitter/Uber/Instagram")
• The interviewer expects you to know the product's user-facing behavior
• The focus is on end-to-end architecture, not a single component
• Estimation and scoping are critical - the product is too big to design fully in 45 minutes

The trap: Designing a generic "social media app" instead of making specific, opinionated choices. The interviewer wants to hear your decisions - "I'd use a push-based fanout model because..." not "we could use push or pull."

Where product design questions show up most: Meta, Google, and most startups love this format. Amazon uses it occasionally but leans more toward infrastructure design.

A Worked Framework for Product Design

Here's a reusable scaffold you can apply to any product design question. Think of it as a checklist, not a script - you should adapt the conversation naturally, but make sure you cover each step.

flowchart LR
    A[Step 1:<br/>Functional<br/>Requirements] --> B[Step 2:<br/>Non-Functional<br/>Requirements]
    B --> C[Step 3:<br/>Capacity<br/>Estimation]
    C --> D[Step 4:<br/>API<br/>Design]
    D --> E[Step 5:<br/>Data<br/>Model]
    E --> F[Step 6:<br/>High-Level<br/>Architecture]
    F --> G[Step 7:<br/>Deep Dives]

This flowchart shows seven steps for product design interviews. Step 1 is functional requirements. Step 2 is non-functional requirements. Step 3 is capacity estimation. Step 4 is API design. Step 5 is data model. Step 6 is high-level architecture. Step 7 is deep dives into specific components.

Step 1 - Functional Requirements: What does the system do? List three to five core features. "Users can post tweets. Users can follow other users. Users can view a personalized timeline."

Step 2 - Non-Functional Requirements: What qualities must the system have? Latency targets, availability, consistency model, durability. "Timeline rendering should be under 200ms. The system should be highly available - we can tolerate eventual consistency for timeline updates."

Step 3 - Capacity Estimation: How much load, data, and traffic? Do the napkin math. "500 million tweets per day is about 6,000 per second. Each tweet is about 1 KB with metadata. That's 500 GB of new tweet data per day, or about 180 TB per year."

Step 4 - API Design: What endpoints does the system expose? Keep this quick - just the core operations. POST /tweets, GET /timeline, POST /follow/{userId}. Don't design a full REST API; sketch the critical paths.

Step 5 - Data Model: What are the core entities and relationships? Users, tweets, follows, likes. What storage engine fits? SQL for relationships, NoSQL for timeline data, a combination of both.

Step 6 - High-Level Architecture: Draw the boxes and arrows. This is where you show the big picture.

Step 7 - Deep Dives: The interviewer picks components to explore. Be ready for "How does the timeline actually get assembled?" and "What happens when a celebrity with 50 million followers posts a tweet?"

Type 2: Infrastructure Design

Examples: "Design a rate limiter," "Design a distributed cache," "Design a job scheduler," "Design a pub/sub messaging system," "Design a content delivery network."

What it tests: Your understanding of low-level infrastructure components. These questions don't have a consumer product attached - they're about building a piece of the plumbing that other systems sit on top of.

How to approach it:

Infrastructure design questions are narrower in scope but deeper in technical expectations. The interviewer doesn't need you to scope a product - the scope is already clear. Instead, they need you to demonstrate deep understanding of the component you're designing.

1. Clarify the API surface. What operations does this component expose? A rate limiter has allowRequest(clientId). A distributed cache has get(key), set(key, value, ttl), delete(key). Define the interface first.

2. Identify the hard constraint. Every infrastructure component has a defining constraint. For a rate limiter, it's accuracy under distributed load. For a distributed cache, it's consistency across nodes. For a job scheduler, it's exactly-once execution. Name the constraint early - it shows the interviewer you understand the problem.

3. Present multiple algorithms or approaches. Infrastructure design questions almost always have multiple valid algorithms. A rate limiter could use token bucket, sliding window, fixed window, or leaky bucket. Don't just pick one - present two or three, compare their tradeoffs, and then choose. This is where senior-level signal lives.

4. Design for distributed operation. The interviewer wants to see you handle the "distributed" part. A rate limiter on a single machine is trivial. A rate limiter across ten machines that must maintain accurate counts - that's the real problem.

Interview: Infrastructure Design question signals:

• The question names a technical component, not a consumer product
• The scope is narrow but depth expectations are high
• The interviewer expects you to present multiple approaches and choose one with reasoning
• Distributed operation is always part of the problem

The trap: Designing only the single-machine version. "I'd use a hash map to count requests per client" - great, but what happens when you have 20 API servers? How do they share state?

Where infrastructure design questions show up most: Amazon (heavily), Google, and companies with significant infrastructure teams. Meta and Apple use them less frequently.

Key Differences from Product Design

Type 3: Deep Dive on a Known System

Examples: "Walk me through how Google Search works at scale," "How would you improve Netflix's recommendation system?" "Explain how a CDN like CloudFront handles cache invalidation," "You're on the Gmail team - how would you reduce email delivery latency by 50%?"

What it tests: Whether you can reason about a real, complex, existing system. The interviewer is checking whether you understand how production systems actually work - not textbook versions, but messy, compromised, evolved-over-ten-years versions.

How to approach it:

This question type is common at senior and staff levels. It's rare for new grads because it requires production experience to answer well.

1. State what you know about the system. You don't need to know every detail - but you should have a reasonable mental model. "My understanding is that Google Search has three major stages: crawling, indexing, and serving. The crawler discovers pages, the indexer processes and ranks them, and the serving layer responds to queries against the index."

2. Identify the constraint the question is about. "How would you improve X?" means there's a specific problem to focus on. Ask: "When you say improve, are you thinking about latency, throughput, cost, or reliability?" Don't improve everything at once.

3. Propose specific, defensible changes. Not "make it faster" but "move the ranking computation from the serving path to an offline precomputation step, trading freshness for latency." Specific proposals show engineering judgment.

4. Discuss second-order effects. If you precompute rankings, what do you lose? Freshness - a tweet that goes viral in the last five minutes won't appear in precomputed results. The interviewer wants to hear you reason about the ripple effects of your change.

Interview: Deep Dive question signals:

• The question references a real system or company
• You're asked to "improve," "redesign," or "walk through" something that already exists
• The interviewer expects you to have working knowledge of the system's architecture
• Proposals need to be specific and include second-order effects

The trap: Making changes without understanding the current system. If you don't know how Netflix's recommendation system works today, you can't meaningfully improve it. It's okay to say, "Here's my understanding - correct me if I'm off."

Where deep dive questions show up most: Google (especially for senior+), Netflix, and any company where you'd be working on an existing large-scale system rather than building from scratch.

Type 4: Open-Ended Greenfield

Examples: "Design a system that detects fraudulent transactions in real time," "Design a global disaster alert system," "Design a system that lets autonomous vehicles communicate with each other."

What it tests: Your ability to handle genuine ambiguity. Unlike product design questions where you can anchor on a known product, greenfield questions often describe something that doesn't exist yet or that you've never personally used. The interviewer wants to see how you navigate uncertainty.

How to approach it:

1. Don't panic about not knowing the domain. You're not expected to be a fraud detection expert or an autonomous vehicle engineer. You're expected to apply system design principles to a new domain.

2. Spend extra time on requirements. Since you can't anchor on a known product, you need the interviewer to help you scope. "When you say 'detect fraudulent transactions in real time,' are we talking about credit card transactions? What's the volume? What's the acceptable false positive rate? Is there a human review step, or is the system fully automated?"

3. Map the problem to known patterns. Every greenfield problem is actually a combination of known patterns. A real-time fraud detection system is: a stream processing pipeline + a classification model + an alerting system + a human review queue. You've seen each of these pieces before. The novelty is in the combination, not the components.

4. Be explicit about assumptions. "I'm going to assume we're processing credit card transactions at a volume of about 10,000 per second. I'm assuming we need sub-second decisions because the transaction is being held pending approval. I'm assuming a 0.1% fraud rate, so about 10 fraudulent transactions per second."

flowchart TD
    A[Greenfield Question] --> B{Can you map it to<br/>a known product?}
    B -->|Yes| C[Treat as<br/>Product Design]
    B -->|No| D[Spend extra time<br/>on requirements]
    D --> E[Identify the core<br/>data flow]
    E --> F[Map to known<br/>patterns]
    F --> G[Design from<br/>first principles]
    G --> H[State assumptions<br/>explicitly]

This flowchart shows how to approach greenfield system design questions. First, determine if you can map the problem to a known product. If yes, treat it as product design. If no, spend extra time on requirements, identify the core data flow, map it to known patterns, design from first principles, and state all assumptions explicitly.

Interview: Greenfield question signals:

• The question describes something you've never used or that doesn't exist
• There's no well-known product to anchor on
• The interviewer expects you to navigate ambiguity
• Requirements gathering is critical - you'll need to make and state assumptions

The trap: Freezing because you don't know the domain. The interviewer doesn't expect domain expertise. They expect system design thinking applied to a new domain.

Where greenfield questions show up most: Google (especially Brain and Research teams), startups, and companies building new product categories. Less common at Amazon and Meta, which prefer product design and infrastructure design questions.

How to Recognize the Type in the First 30 Seconds

Here's a quick decision framework. The moment the interviewer finishes the question, ask yourself:

flowchart TD
    A[Interviewer asks<br/>the question] --> B{Does it name a<br/>consumer product?}
    B -->|Yes| C{Is it about building<br/>it from scratch?}
    B -->|No| D{Is it about a<br/>specific component?}

    C -->|Yes| E["Type 1:<br/>Product Design"]
    C -->|No, it's about<br/>improving it| F["Type 3:<br/>Deep Dive"]

    D -->|Yes - rate limiter,<br/>cache, scheduler| G["Type 2:<br/>Infrastructure Design"]
    D -->|No - novel problem| H["Type 4:<br/>Greenfield"]

This decision tree helps identify the system design question type. If the question names a consumer product and asks you to build it from scratch, it's Type 1 Product Design. If it asks you to improve a known product, it's Type 3 Deep Dive. If it names a specific infrastructure component, it's Type 2 Infrastructure Design. If it describes a novel problem, it's Type 4 Greenfield.

The reason this matters is that each type has a different entry point. If you start a Type 2 Infrastructure Design question with "Let me first list the functional requirements for end users..." - you're using the wrong playbook. There are no end users. The users are other systems.

Warning: Common mistake: using the Product Design playbook for every question. Many candidates have practiced only one approach - the "clarify requirements → estimate scale → draw architecture" script. That works for Type 1. It's awkward for Type 2 (infrastructure has no "users" in the consumer sense). It's wrong for Type 3 (you should start with what exists, not from scratch). And it's incomplete for Type 4 (you need to spend more time on domain mapping). Match your approach to the question type.

Company Tendencies

Different companies lean toward different question types. This isn't a guarantee - any company can ask any type - but knowing the tendencies helps you prioritize your preparation.

Tip: Before your interview: Research the specific company's system design question style on Glassdoor, Blind, and interview prep forums. Knowing whether you'll face a product design or infrastructure design question lets you calibrate your preparation. You can't prepare for everything - but you can prepare for the likely question type.

Six Key Takeaways

1. There are four distinct types of system design questions: product design, infrastructure design, deep dive on known systems, and open-ended greenfield. Each needs a different approach.
2. Recognizing the question type in the first 30 seconds saves you from using the wrong playbook.
3. Product design questions are the most common - but not the only type. Over-preparing for one type at the expense of others is a risk.
4. Infrastructure design questions demand deeper technical knowledge of algorithms and distributed coordination. The "users" are other systems, not consumers.
5. Deep dive questions require production experience or strong mental models of existing systems. They're most common at senior and staff levels.
6. Greenfield questions test your ability to apply known patterns to new domains. The key is mapping the unfamiliar problem to familiar components.

Exercises

Exercise: Exercise 1: For each question below, identify the question type (1-4) and your first action:

• "Design Spotify"
• "Design a distributed lock service"
• "How would you reduce cold-start latency in AWS Lambda?"
• "Design a system that detects plagiarism across millions of documents"

Exercise 2: Pick one company from the table above that you're interviewing with. Research three recent system design questions reported on Glassdoor or Blind. Classify each by type. How well does the company tendency table predict what you found?

Exercise 3: Take a product design question ("Design Instagram") and reframe it as a deep dive question ("How would you redesign Instagram's Explore page to improve engagement?"). Notice how the entry point changes - from building from scratch to understanding and improving.

Resources

• Glassdoor Interview Reviews - Filter by company and role for real interview questions
• Blind - Interview Experiences - Anonymous reports of interview questions by company
• System Design Primer (GitHub) - Open-source collection of system design topics and practice questions
• ByteByteGo Newsletter - Weekly system design case studies by Alex Xu

Back to System Design Interviews