Welcome to your second lesson on frontend system design. In our previous session, we established a high-level map of the interview landscape, introducing the RADIO framework as our guide. You learned that these interviews are less about finding a single correct answer and more about showcasing a structured, thoughtful approach to problem-solving.
Today, we delve into the first and arguably most critical step of that framework: the 'R' for Requirements. Mastering this phase is the key to setting yourself up for success. An interview prompt like "Design a news feed" is deliberately ambiguous. Your first task is not to design, but to define. By the end of this lesson, you will be able to confidently gather and clarify both functional and non-functional requirements, transforming a vague problem into a well-defined set of engineering challenges.
What vs. How: The Two Types of Requirements
At its core, requirements gathering is about answering two fundamental questions: What should the system do? And how well should it do it? This distinction separates requirements into two categories: functional and non-functional.
A great analogy, shared in the "Real Frontend System Design" video, is that of building an airplane.
Frontend System Design to get to Senior Engineer
This video from theSeniorDev provides a clear and memorable analogy to distinguish between functional and non-functional requirements.
Watch the initial segment from the beginning. Pay attention to how the airplane analogy separates the "what" (engines, seats) from the "how" (fuel consumption, noise level).
-
Functional Requirements define what the system does. They are the specific features and user actions, the core tasks the application must perform to be useful. Think of these as the nouns and verbs of your system: a user can upload a photo, view a product, or add an item to a cart.
-
Non-Functional Requirements (NFRs), also known as quality attributes, define how the system performs. They describe the properties and constraints of the system, such as its speed, security, and reliability. These are the adjectives and adverbs: the page must load quickly, the data must be transmitted securely, and the UI must be accessible.
For a frontend system design interview, understanding NFRs is paramount. As the "Frontend System Design Guide" highlights, they are what drive major architectural decisions.
Frontend System Design: The Complete Guide 2026
This guide explains why non-functional requirements are so heavily weighted in frontend system design interviews.
Please read the section Identifying functional and non-functional requirements. Note the connection it draws between NFRs like performance and accessibility and the architectural choices they influence, such as rendering strategy and component design.
The table below provides a more detailed comparison of these two types of requirements, which can serve as a useful mental model.
The Art of Clarification
In an interview, you will not be handed a neat list of requirements. You are expected to elicit them. A common mistake is to passively ask, "What are the requirements?" A senior engineer, by contrast, drives the conversation. You should treat the interviewer as a product manager or stakeholder and collaboratively define the scope of the project.
The best way to do this is to take the initiative: propose a set of core features and constraints, and then seek alignment.
The RADIO Framework | Front End System Design Playbook
This article from Great Frontend, the authoritative source on the RADIO framework, explains the process of requirements exploration.
First, read the section on Requirements exploration to understand the objective and why you should treat the interviewer as a product manager. Then, review the subsection What are the functional and non-functional requirements?, which describes the preferred strategy of proposing requirements and getting feedback.
As you discuss and agree upon requirements, write them down on the virtual whiteboard or shared document. This simple act has multiple benefits: it shows structured thinking, ensures you and the interviewer are aligned, and provides a checklist you can refer back to throughout the interview.
A Framework for Asking "Smart Questions"
To guide your conversation, you can follow a structured approach to questioning, moving from the broad "what" to the specific "how."
1. Clarify Functional Requirements (Scoping the "What")
Start by narrowing the scope. If the prompt is "Design YouTube," you can't design the entire platform. You must focus on a core set of features.
Example: Designing a Facebook News Feed
Let's see how this is done in practice. The following video demonstrates how to break down a vague prompt into a concrete set of functional requirements.
Front End System Design Fundamentals (All In One Comprehensive Guide)
In this video, Shivam Bhalla walks through the requirements gathering phase for designing a Facebook news feed.
Watch the section from <to_be_replaced> where the presenter defines the core functional requirements, such as displaying a list of items, handling different post types, and implementing infinite scroll. Note how he deliberately limits the scope (e.g., only user posts, not sponsored posts).
You should aim to define:
- Core Use Cases: What are the 1-3 primary things a user comes here to do? (e.g., View posts, create a post, interact with a post).
- Feature Prioritization: Which features are "must-haves" for the Minimum Viable Product (MVP) and which are "nice-to-haves" that can be considered later?
2. Elicit Non-Functional Requirements (Defining the "How")
This is where you demonstrate seniority. The questions you ask about NFRs reveal your understanding of real-world engineering constraints. A great set of "smart questions" can make you stand out even more than the answers you give.
The "Real Frontend System Design" video provides an excellent list of such questions.
Frontend System Design to get to Senior Engineer
This part of the video is crucial. It gives you a vocabulary of "smart questions" to ask to uncover the critical non-functional requirements that will shape your design.
Watch the segment from this timestamp. As you watch, consider categorizing these questions. They touch upon: Scale & Traffic: How many users? Are there traffic spikes? Users & Devices: What are the target devices and browsers? Performance: Is loading speed critical (e-commerce) or is interaction speed more important (SaaS)? Accessibility & Security: Are there specific compliance or security needs (government, banking)?
By asking these questions, you are no longer just a developer waiting for a spec; you are an engineer actively shaping the product by considering its operational context.
From Requirements to Concrete Numbers
The answers to your questions about NFRs, especially scale, should lead you to make some initial estimations. This process, often called "back-of-the-envelope" calculation, is how you translate a business requirement like "millions of users" into an engineering problem like "handle 20 million page views per hour."
Let's see how the information gathered from asking smart questions about Amazon.com is translated into concrete numbers.
Frontend System Design to get to Senior Engineer
This segment demonstrates the direct outcome of requirements gathering: turning user numbers into traffic estimates.
Watch from this timestamp. The goal here is not to memorize the exact numbers for Amazon. Instead, focus on the process: how a high-level number (monthly visits) is broken down into a concrete, actionable metric (peak page views per hour).
Seeing this process should make it clear why requirements gathering is so vital. The output of this stage—a clear scope and a set of constraints—directly informs every subsequent architectural decision you will make, from choosing a rendering pattern to designing your data fetching strategy.
Conclusion
In this lesson, we've dissected the first step of the RADIO framework, focusing on how to effectively gather and clarify requirements. You've learned that this is an active, not a passive, process, driven by your ability to ask insightful questions.
Here are the key takeaways:
- Functional vs. Non-Functional: Functional requirements define what a system does, while non-functional requirements define how it performs. NFRs (performance, scalability, security) are the primary drivers of architectural decisions in frontend system design.
- Be Proactive: Don't wait for requirements. Propose a scope based on core features and seek alignment with the interviewer. This demonstrates leadership and a senior mindset.
- Ask Smart Questions: Your questions about scale, user context, performance targets, and other NFRs are a powerful signal of your experience and architectural thinking.
- Write It Down: Explicitly documenting the agreed-upon requirements on a whiteboard creates clarity and provides a roadmap for the rest of the interview.
In our next lesson, we will build directly on what we've learned today. We will take a deeper dive into the "back-of-the-envelope" calculations we just previewed, and you'll learn how to systematically estimate scale, data, and traffic requirements for a frontend system.