Understanding the Problem: The Foundation of System Design

Every great system design begins long before the first component is drawn. It begins with a single, deceptively simple act: reading the requirements carefully.

This sounds trivial—of course you read the requirements. But there's a profound difference between reading and understanding, between scanning for keywords and systematically extracting the complete problem specification. This difference determines whether you build the right system or an impressive system that solves the wrong problem.

Consider this: in system design interviews at top companies (Google, Meta, Amazon, Netflix), the most common failure mode is not a weak technical design—it's solving the wrong problem. Candidates dive into architecture, sketch out databases and load balancers, only to realize ten minutes later that their interviewer expects something entirely different. The same pattern plays out in production engineering: teams spend months building systems that meet every stated requirement, yet fail spectacularly because unstated—but critical—requirements were never identified.

In system design, all subsequent decisions flow from your understanding of the requirements. Choose the wrong data model, and you can often refactor. Choose the wrong caching strategy, and you can adjust. But misunderstand the fundamental problem, and no amount of elegant engineering can save you.

This isn't hyperbole. Let me illustrate with a concrete example.

The Leverage Principle:

In engineering, leverage refers to how much output you get for a given input. Consider where in the design process your decisions have the most impact:

This is why experienced engineers spend what seems like a disproportionate amount of time on requirements. It's not hesitation—it's wisdom. Getting requirements right is 1000x cheaper than fixing them in production.

System design requirements come in many forms: a single sentence from an interviewer, a page-long product specification, or a casual conversation with a stakeholder. Regardless of format, every requirement can be decomposed into specific components. Mastering this decomposition is the first technical skill in requirements reading.

The Six Components of Any Requirement:

Every system design problem, whether for an interview or a real project, contains (explicitly or implicitly) these six fundamental components:

1. The Actor (Who): The entity initiating or experiencing the system's behavior
2. The Action (What): The core operation being performed
3. The Object (On What): The entity being acted upon
4. The Constraint (Under What Conditions): The limitations and boundaries
5. The Quality (How Well): The performance and reliability expectations
6. The Context (Why): The business purpose and broader ecosystem

The Extraction Process:

When you receive a requirement, work through each component systematically:

Step 1: Identify what's explicitly stated

Read the requirement and mark which components are explicitly mentioned. In our URL shortener example, only the action (shortening URLs) is truly explicit.

Step 2: Note what's implied

Some components are implied by context. 'Like bit.ly' implies public web access, implies HTTP redirects, implies some level of analytics.

Step 3: List what's completely missing

This is the danger zone. Make a list of components that remain unclear even after considering implications. These become your clarifying questions.

Step 4: Assess risk for each gap

Not all missing information is equally dangerous. Missing scale requirements can lead to 100x over- or under-engineering. Missing analytics requirements might only affect a minor feature.

Moving from unconscious reading to deliberate, systematic extraction requires specific techniques. These aren't intuitive—they must be learned and practiced. The following techniques are used by Staff+ engineers and system design experts worldwide.

Awareness of common mistakes is half the battle. These pitfalls trap engineers at all levels—recognizing them helps you avoid joining them.

After reading requirements comes questioning. But not all questions are equal. High-quality questions reveal more information with fewer words. This framework helps you formulate questions that efficiently close information gaps.

The SCOPE Question Framework:

Each letter represents a category of questions. Together, they cover the complete design space:

Question Quality Spectrum:

Not all questions advance your understanding equally.

Low-Value Questions:

• Binary (yes/no) questions when ranges would be more informative
• Questions that confirm assumptions instead of testing them
• Questions disconnected from architectural decisions

Example (Low-Value): 'Will there be users?' → Obviously yes; tells you nothing

Medium-Value Questions:

• Questions that narrow ranges but still leave ambiguity
• Questions that test single assumptions

Example (Medium-Value): 'Will there be more than a million users?' → Binary, but at least establishes scale

High-Value Questions:

• Questions that directly impact architectural choices
• Questions that reveal multiple pieces of information at once
• Questions that surface hidden constraints

Example (High-Value): 'What's the expected daily active user count, and how does it vary throughout the day?' → Reveals scale AND traffic patterns AND helps design for peak vs average load

Reading is not complete until understanding is documented. This serves two purposes:

1. External verification: Stakeholders can confirm or correct your understanding
2. Internal clarity: Writing forces you to confront gaps in your own understanding

The Requirement Summary Format:

After reading and questioning, produce a structured summary. This becomes your design's foundation document.

Why This Format Works:

• Problem Statement forces conciseness—if you can't summarize in two sentences, you don't understand yet
• Core Functionality separates must-haves from nice-to-haves
• Non-Functional Requirements makes implicit expectations explicit
• Scale Estimates quantifies the problem (designs differ 10x based on scale)
• Constraints documents what limits your options
• Assumptions makes risks visible—unconfirmed assumptions are design risks
• Out of Scope prevents scope creep by explicitly excluding features
• Open Questions tracks what must be resolved before (or during) design

Let's apply everything we've learned to a real system design prompt. Walk through this case study actively—don't just read, actually practice the techniques.

The Prompt:

Design a notification system for a large-scale social media platform.

We've covered the first and most critical step in any system design exercise. Let's consolidate the key takeaways:

What's Next:

Reading requirements carefully gives you raw information. The next page explores how to identify scope and constraints—transforming that raw information into the boundaries that shape your design. You'll learn to distinguish between the essential and the optional, the flexible and the fixed, the now and the later.