Session 6.1: Step 1: Understand the Problem

Course → Module 6: System Design Interview Framework

Why Requirements Come First

Most candidates, when given a system design prompt, start drawing boxes within 30 seconds. Load balancer here, database there, maybe a cache for good measure. Five minutes later, the interviewer asks: "Does this system need to support group messaging?" The candidate pauses. The entire diagram is wrong.

The first five minutes of a system design interview are the most valuable. Not because you produce a diagram, but because you produce clarity. Every minute spent understanding the problem saves eight minutes of wasted design. The ratio is not metaphorical. If you design for the wrong requirements, you will either backtrack painfully or deliver a system that solves the wrong problem.

The best system designers spend 20% of their time on requirements and 80% on the right problem. Everyone else does the opposite.

The Two Categories of Requirements

System requirements split into two categories, and confusing them is a common failure mode.

Functional requirements describe what the system does. These are features visible to the user. "Users can send text messages." "Users can create group chats with up to 256 members." "Messages are delivered in order within a conversation." If you removed a functional requirement, the user would notice immediately because a feature is missing.

Non-functional requirements describe how the system behaves. These are qualities of the system that users experience but do not directly request. Latency under 200ms. 99.99% availability. End-to-end encryption. If you violated a non-functional requirement, the system would still technically work, but it would be slow, unreliable, or insecure.

The distinction matters because functional requirements determine your architecture (what services you build), while non-functional requirements determine your infrastructure (how you build and deploy them).

The Requirement-Gathering Process

Requirement gathering in an interview is not random questioning. It follows a structured flow. Start broad, then narrow. Confirm the scope, then dig into specifics.

flowchart TD A["Restate the problem
in your own words"] --> B["Identify core use cases
(the 2-3 must-haves)"] B --> C["Ask about users
Who? How many? Where?"] C --> D["Clarify functional requirements
What does the system do?"] D --> E["Clarify non-functional requirements
Latency, availability, consistency?"] E --> F["Identify constraints
Budget, timeline, existing infra?"] F --> G["Confirm scope with interviewer
What is in/out?"] G --> H["Summarize and proceed
to estimation"] style A fill:#222221,stroke:#c8a882,color:#ede9e3 style B fill:#222221,stroke:#c8a882,color:#ede9e3 style C fill:#222221,stroke:#6b8f71,color:#ede9e3 style D fill:#222221,stroke:#6b8f71,color:#ede9e3 style E fill:#191918,stroke:#c47a5a,color:#ede9e3 style F fill:#191918,stroke:#c47a5a,color:#ede9e3 style G fill:#191918,stroke:#8a8478,color:#ede9e3 style H fill:#191918,stroke:#8a8478,color:#ede9e3

Notice the structure. You do not jump straight to "How many requests per second?" That question only makes sense after you know what kind of requests the system handles. You also do not start listing features without confirming users and use cases.

The Categorized Checklist

Use this table as a mental checklist during the requirement-gathering phase. Not every question applies to every problem, but scanning through the categories ensures you do not miss a critical dimension.

Category	Questions to Ask	Why It Matters
Functional	What are the core features? Who are the actors? What actions can each actor perform? What data flows in and out?	Determines the services you build and the APIs you expose
Non-functional	What latency is acceptable? What availability target (99.9%? 99.99%)? Strong or eventual consistency? Any compliance requirements (GDPR, HIPAA)?	Drives infrastructure choices: replication, caching, regional deployment
Scale	How many users (DAU/MAU)? Read-heavy or write-heavy? Peak traffic vs. average? Data growth rate?	Determines whether you need sharding, caching, CDN, or async processing
Constraints	Existing tech stack? Budget limitations? Team size? Must it run on specific cloud? Mobile, web, or both?	Eliminates options early and keeps the design realistic
Edge Cases	What happens during failures? How do we handle duplicate submissions? What about network partitions? Offline support?	Separates a good design from a great one. Interviewers probe these.

The Art of Scoping

A system design interview is typically 45 to 60 minutes. You cannot design an entire production system in that time. Scoping is the skill of deciding what to include and what to defer.

Here is the principle: focus on the core flow that makes the system unique. For a chat application, the core flow is sending and receiving messages. Group management, profile pictures, and story features are secondary. For a URL shortener, the core flow is shortening a URL and redirecting to the original. Analytics dashboards and custom aliases are secondary.

Explicitly state what you are including and what you are excluding. "I will focus on one-to-one messaging and message delivery guarantees. I will defer group messaging, media sharing, and presence indicators unless we have time." This shows the interviewer that you understand prioritization, not that you are avoiding complexity.

Common Mistakes in Requirement Gathering

Assuming instead of asking. "I assume we need to handle 1 billion users." Why assume? Ask. The interviewer might say 10 million, and that changes your entire architecture.

Asking too many questions. Spending 15 minutes on requirements in a 45-minute interview leaves too little time for design. Aim for 5 minutes. Be focused, not exhaustive.

Ignoring non-functional requirements entirely. Many candidates list features but never ask about latency, consistency, or availability. These are the requirements that determine your technical decisions.

Not summarizing. After gathering requirements, state them back to the interviewer. "So we are designing a one-to-one chat system for 500 million DAU, with sub-200ms message delivery, 99.99% availability, and end-to-end encryption. I will focus on message send/receive and delivery guarantees. Does that sound right?" This alignment check prevents you from designing the wrong system.

Worked Example: "Design WhatsApp"

The interviewer says: "Design WhatsApp." Here is how the first five minutes should go.

Restate: "WhatsApp is a real-time messaging application. I want to make sure I design the right subset. Let me ask a few questions."

Users and scale: "How many daily active users should I design for? Are we targeting global users across multiple regions?"

Core features: "Should I focus on one-to-one messaging only, or also group chats? Do we need media sharing (images, video), or just text? What about read receipts and online status?"

Non-functional: "What is the acceptable message delivery latency? Should messages be encrypted end-to-end? Do we guarantee message ordering? If a user is offline, do we store messages for later delivery?"

Constraints: "Should this work on both mobile and web? Do we need to support very low-bandwidth connections?"

Scope confirmation: "Based on your answers, I will focus on one-to-one text messaging with offline delivery and end-to-end encryption for 500 million DAU. I will defer group messaging, media, and stories."

Total time: about four minutes. The interviewer now knows you understand the problem, and you have a clear scope for the remaining 40 minutes.

Assignment

You are asked: "Design WhatsApp." Before drawing a single box, write 10 clarifying questions. Organize them into the five categories from the checklist table above (functional, non-functional, scale, constraints, edge cases). For each question, write one sentence explaining why the answer would change your design.

Step 1: Understand the Problem