5-Step System Design Interview Framework

Why a Framework is Essential

System design questions are intentionally broad, like "Design a URL shortener" or "Design the backend for TikTok." Without a structured approach, it's easy to get lost, jump to premature conclusions, or fail to address the interviewer's core concerns. A framework turns this ambiguous problem into a systematic process.

Let's begin with a short video that explains the purpose of system design interviews and why a framework is so critical for success.

As the video highlights, the interview tests your ability to analyze a problem, discuss solutions, and weigh trade-offs. The framework is your tool to do this effectively under pressure.

The 5-Step System Design Interview Framework

We will now break down a comprehensive 5-step framework. While different resources might present slight variations, the core principles are consistent. This framework is your roadmap for the interview.

To get a solid grasp of this framework, let's start with a foundational reading.

Now, let's dissect each step, integrating senior-level considerations and showing how it looks in practice. For each step, we'll see a real candidate apply it in a mock interview.

Step 1: Understand the Problem and Define Scope (~5-7 minutes)

This is the most critical phase. A mistake here can derail the entire interview. Your goal is to transform the vague prompt into a concrete set of requirements.

Key Actions:

1. Clarify Functional Requirements: These are the features the system must have. Ask questions to narrow the scope.
   • Example for "Design TikTok": "Should users be able to upload videos? View a feed? Follow other users? Comment or like videos?" Focus on the top 3-4 core features.
2. Define Non-Functional Requirements (NFRs): These are the system's qualities. This is where you connect to production realities.
   • Availability: Is this a highly available system (e.g., 99.99%)? What's the trade-off with consistency (CAP Theorem)?
   • Latency: What are the response time targets for key operations (e.g., feed generation < 200ms)?
   • Durability: How critical is it that we don't lose data (e.g., user videos)?
   • Scalability: How many users should we support (e.g., 1 million Daily Active Users)? What is the read/write ratio? (e.g., TikTok is very read-heavy).
3. Make Scale Estimations (Back-of-the-envelope math): Use the NFRs to estimate key figures like Queries Per Second (QPS), storage needs, and bandwidth. This isn't about perfect math; it's about getting a sense of the system's scale to justify later design choices (e.g., "The storage is in petabytes, so we'll need a distributed object store like S3, not just a server's disk").

Watch it in action:

Step 2: High-Level Design and API Definition (~10 minutes)

Now that you have the requirements, you'll sketch the 30,000-foot view of the system. The goal is to create a simple, working design that meets the core functional requirements.

Key Actions:

1. Define the API Contract: How will clients interact with your system? Choose a protocol (REST is a safe default) and define the main endpoints.
   • Example for TikTok:
     • POST /v1/videos: Upload a video.
     • GET /v1/feed: Get the user's video feed.
     • POST /v1/users/{userId}/follow: Follow a user.
   • Senior Insight: As noted in the Google L5 System Design guide, think about versioning (/v1/) from the start.
2. Draw the High-Level Architecture: Use boxes and arrows to represent the main components and data flows.
   • Start with the client (mobile/web app).
   • Add a Load Balancer.
   • Add your main Backend Service(s) (Application Servers).
   • Add a Database.
   • For a media-heavy site, add an Object Store (like S3) for large files.
   • Keep it simple. Don't add caching, message queues, or complex scaling patterns yet. Just get a basic end-to-end flow working.

Watch it in action:

Step 3: Deep-Dive into Specific Components (~15 minutes)

With the high-level design in place, you or the interviewer will pick a specific, interesting area to explore in more detail. This is where you demonstrate depth.

Key Actions:

1. Choose a Component: This is often the most complex part of the system or one related to a critical NFR. For TikTok, it would be the feed generation. For a URL shortener, it might be the hash generation and storage.
2. Flesh out the Design:
   • Data Model: Detail the database schema for the chosen component. What tables, columns, and indexes are needed? (e.g., Users, Videos, Follows tables).
   • Logic: Explain the algorithm or workflow. How is the TikTok feed generated? (e.g., "We could have a service that pre-computes feeds and stores them in a cache for low latency").
   • Trade-offs: Discuss alternatives. Why SQL vs. NoSQL here? What are the pros and cons of pre-computing feeds vs. generating them on the fly?

Watch it in action:

Step 4: Identify Bottlenecks and Scale the Design (~10 minutes)

Now, revisit your design with a critical eye, focusing on the NFRs for scalability and reliability. How does this system hold up at 10x or 100x the initial scale?

Key Actions:

1. Identify Bottlenecks and Single Points of Failure (SPOFs): Where will the system break under load?
   • Is the single database going to be a bottleneck?
   • Is the application server stateless so it can be scaled horizontally?
   • Is the load balancer a SPOF?
2. Introduce Scaling Patterns: Evolve your high-level diagram by adding components to address these issues.
   • Load Balancing: Add more application servers behind the load balancer.
   • Database Scaling: Add read replicas for read-heavy workloads. For write-heavy workloads, discuss database sharding.
   • Caching: Add a distributed cache (like Redis or Memcached) to reduce database load.
   • CDN: For globally distributed users and static assets (like video), add a Content Delivery Network.
   • Asynchronous Processing: Introduce message queues (like RabbitMQ or SQS) to decouple services and handle background tasks.

Watch it in action:

Step 5: Wrap Up: Final Touches and Summary (~5 minutes)

In the final minutes, you should summarize your design and touch on any remaining points.

Key Actions:

1. Summarize: Briefly walk the interviewer through your final diagram, explaining how it meets the key requirements.
2. Discuss Further Improvements: Show you're thinking ahead.
   • Observability: "To operate this system, I would add detailed monitoring, logging, and tracing. We would define SLOs for key services and set up alerts." (Directly connects to our previous lesson!)
   • Security: "We'd need to consider authentication, authorization, and protecting against common vulnerabilities."
   • Deployment: "We would use a CI/CD pipeline with blue-green deployments to release changes safely."
3. Reiterate Trade-offs: Briefly mention one or two key trade-offs you made (e.g., "We prioritized availability by using asynchronous replication, accepting some data lag"). This is a very strong signal of seniority, as highlighted in the Google L5 System Design guide.

Conclusion

You now have a robust, repeatable framework for any system design interview. This process ensures you cover all the critical aspects that interviewers evaluate: problem analysis, architectural design, deep technical knowledge, and an understanding of real-world operational constraints.

Key Takeaways:

• Structure is Key: A 5-step framework (Requirements, High-Level Design, Deep-Dive, Scaling, Wrap-up) is your most valuable tool.
• Start with 'Why' and 'What': Don't jump into implementation. Spend quality time on clarifying functional and non-functional requirements.
• Iterate your Design: Start simple, then layer on complexity. Build a basic working system first, then scale and harden it.
• Justify Your Decisions: The goal is to showcase your thought process. For every component you add, explain why you're adding it and what problem it solves.
• Talk About Trade-offs: Demonstrating that you understand there's no single "right" answer and that every decision has consequences is a hallmark of a senior engineer.

Preview of the Next Lesson:

In this lesson, you learned the process of system design. In the next few lessons, we'll deep-dive into the fundamental building blocks you'll use within that process. We'll start with "Horizontal vs. Vertical Scaling," a core concept you briefly touched upon today, and explore its implications for cost, complexity, and performance.