Keep in mind that the end goal of systems design is to explain in great detail how to architect a system and address its core technical challenges rather than listing out all of the product's features.

In-Scope vs Out of Scope
Functional & non-functional

• Focus on the main value creation of the solution
• identify the core of the core feature of the problem
• What is the unique selling feature
• what problem this product solves
• 🚩Non-Functional Req - UX and Performance:
  • Whether UX needs strong consistency vs eventual consistency? (e.g. Smart home automation needs strong consistency).
• Don't do more work than you have to.
• What is special and unique about this system?
• Scale of the system - Don't need to go into too deep in DAU/MUA
  • Just get a sense of scale - not the exact number.
  • That debate - no one can answer accurately.

Don't just ramble around requirement and assumption from your own. Try to engage with
interviewer. e.g. : I am going to assume blah blah, is it looking reasonable?

For non-functional - don't sound "buzz-wordy" - and try to give context related example.

What's in and out of scope? and what area of focus for this problem?
Deprioritize the "generic features like likes, comments etc. unless you're making reddit"

A 45-minute interview is a very time-constrained environment to flesh out a broad design, so we have to narrow the scope to the most essential topics to thoroughly discuss. In this exploration phase, we'll learn how to identify and prioritize the distinct technical challenges in design prompts so that you can address them with a detailed proposal in the remainder of the interview.

We want to avoid diving into standardized technical topics like authentication, authorization, and superficial features.

🧠 Why

Systems design is an ambiguous, open-ended, broad discussion; navigating it is both technical and behavioral. Dissecting a prompt and prioritizing the most critical requirements lets you show your engineering intuition before diving into anything technical!

📚  Purpose

You want to show that you can make progress when dealing with ambiguity and identify the challenges you must solve, even if you may not know how to solve them.
The interviewer is looking for signals from your thought process and communication. Everything you say or draw should showcase your strengths and help the interviewer to evaluate you as a candidate. They do not expect you to create an accurate solution to the real-world system.

What things to keep out of scope?

• Things that can be "off-loaded" to 3rd party solution / existing solution
  • authentication
  • search user/data
• Too complex

How to do it?

Requirement gathering is a crucial step in a System Design Interview, as it helps clarify the problem, define scope, and align expectations. A well-structured approach ensures that you cover both functional and non-functional requirements efficiently.

1. Clarify the Problem Statement

• Ask open-ended questions to get a high-level understanding.
  • Example: "Can you clarify the main goal of this system?"
• Confirm any assumptions upfront.
  • Example: "Are we designing for a new system or improving an existing one?"
• Identify the primary users and their expectations.

2. Define the Functional Requirements or user stories

These specify what the system should do.

• Ask about core features and expected functionality.
  • Example: "What are the key operations the system should support?"
• Identify user interactions with the system.
  • Example: "Will users interact via a web app, mobile app, or API?"
• Understand data flows within the system.
  • Example: "What inputs do we receive, and what outputs do we generate?"

Common Functional Aspects to Cover

✅ CRUD operations (Create, Read, Update, Delete)
✅ Authentication & Authorization (e.g., OAuth, JWT)
✅ Third-party integrations (e.g., Payment, External APIs)
✅ Scalability requirements (future growth considerations)

3. Define the Non-Functional Requirements (NFRs)

These focus on system performance, reliability, and scalability.

• Scalability: Expected number of users or requests per second?
• Performance: Latency expectations for critical operations?
• Availability: Does the system need high uptime (e.g., 99.99%)?
• Consistency vs. Availability (CAP Theorem): Strong vs. eventual consistency?
• Security: Compliance needs (GDPR, HIPAA)?
• Data Storage: SQL or NoSQL? Volume of stored data?
• Failure Handling: How should the system behave in case of failures?

Example questions:

• "What is the expected request per second (RPS) at peak load?"
• "Is this a global system or region-specific?"
• "How important is data consistency vs. availability?"

4. Identify Constraints & Trade-offs

• Time constraints: Is there a deadline for launch?
• Budget constraints: Are there cost considerations (e.g., AWS
• /GCP usage)?
• Tech stack preferences: Any specific technologies to be used?

5. Summarize and Confirm

• Reiterate key functional and non-functional requirements to confirm understanding.
• Example: "To summarize, we need a scalable, low-latency system that supports user authentication, handles X RPS, and ensures 99.9% uptime. Does that align with your expectations?"

Samples

1. Clarifying Requirements - URL Shortener
2. Clarifying Requirements - Straw Poll