Clarify Requirements

The Four Pillars of Clarification

Every system design interview begins with a vague prompt. Your first job is to turn ambiguity into a concrete problem statement. There are four categories of questions you should always ask.

1. Users and Scale

Who uses the system? Understanding your user base drives every downstream decision.

Question	Why It Matters
How many daily active users (DAU)?	Determines replication strategy, cache sizing, database sharding
What is the read-to-write ratio?	100:1 reads suggest heavy caching; 1:1 suggests balanced architecture
Are users global or regional?	Affects CDN placement, data residency, latency requirements
Is the user base growing?	Influences whether you design for horizontal scalability

Example: If asked to design Twitter, you might say:

"I want to confirm the scale. Are we designing for 300M DAU like current Twitter, or a smaller 10M DAU product? And is the read-to-write ratio approximately 100:1, meaning most users scroll timelines rather than tweet?"

2. Latency and Performance

How fast must it be? This drives your choice of databases, caching layers, and async vs sync processing.

• Real-time (< 100ms): Chat, notifications, live feeds → need in-memory stores, persistent connections
• Near real-time (< 1s): Search results, feed loads → can tolerate some network hop
• Batch (minutes to hours): Analytics, recommendations → can use offline processing

3. Consistency vs Availability

Do you need strong consistency or high availability? This is the CAP theorem tradeoff.

Strong Consistency: Every read returns the most recent write
  → Banking transactions, inventory counts
  → Requires consensus protocols (Paxos, Raft)
  → Higher latency, lower availability

Eventual Consistency: Reads may lag behind writes
  → Social media feeds, view counts
  → CRDTs, gossip protocols
  → Lower latency, higher availability

4. Data Characteristics

What kind of data are we storing?

• Structured vs unstructured: Relational DB vs document store vs object storage
• Data volume: GBs vs TBs vs PBs affects storage architecture
• Data retention: Must we keep data forever? Compliance requirements?
• Access patterns: Hot data (frequently accessed) vs cold data (archival)

The Question Framework Template

1. SCALE QUESTIONS
   - "How many users do we expect?"
   - "What is the expected read/write ratio?"
   - "Is the system global or regional?"

2. PERFORMANCE QUESTIONS
   - "What latency is acceptable?"
   - "Do we need real-time or near-real-time?"

3. CONSISTENCY QUESTIONS
   - "Is strong consistency required?"
   - "Can we tolerate eventual consistency?"

4. DATA QUESTIONS
   - "What is the expected data volume?"
   - "What are the primary access patterns?"
   - "Are there retention or compliance requirements?"

Functional vs Non-Functional Requirements

Before diving into architecture, you must separate WHAT the system does from HOW it performs.

Functional Requirements

These define the features and behaviors of the system. They answer: What should the system do?

Example: URL Shortener Functional Requirements
✅ Generate a short URL from a long URL
✅ Redirect short URL to original URL
✅ Custom aliases (optional)
✅ Link expiration
✅ Analytics (click count, geographic data)

Non-Functional Requirements

These define quality attributes. They answer: How should the system behave?

Example: URL Shortener Non-Functional Requirements
⚡ Low latency redirect (< 100ms)
📈 High availability (99.99%)
🔒 URL cannot be guessed
📊 Handle 100M URLs, 1B redirects/day
🗑️ Optional: link expiry and deletion

The Must-Have vs Nice-to-Have Framework

Under 45 minutes, you cannot design everything. Use this prioritization matrix:

Priority	Category	Example (URL Shortener)
P0 - Must Have	Core functionality without which system is useless	URL creation, redirection
P1 - Should Have	Important but system works without it	Custom aliases, basic analytics
P2 - Nice to Have	Enhances UX but not critical	QR codes, bulk creation
P3 - Future	Out of scope for this session	Enterprise features, SSO

The 2-Minute Rule

Spend exactly 2 minutes on requirements. No more. Here is why:

• A 45-minute interview has ~35 minutes of design time
• Spending 5+ minutes on requirements leaves insufficient time for deep-dive
• Interviewers expect you to ask the RIGHT questions, not ALL questions

Execution template:

"Great, let me clarify a few key things:

1. SCALE: What is the expected user base and traffic volume?
2. LATENCY: What are the latency requirements?
3. CONSISTENCY: Do we need strong consistency or is eventual okay?
4. CORE FEATURES: I'll focus on [feature 1], [feature 2], and [feature 3].
   We can discuss [nice-to-have] if time permits.

Is that a reasonable scope?"

This takes ~90 seconds and demonstrates structured thinking.

Scope Narrowing Techniques

Technique 1: Eliminate by Time

"Given our 45-minute window, I'll focus on the core use case of URL creation and redirection. Analytics and custom aliases can be extensions."

Technique 2: Eliminate by Complexity

"I'll skip user authentication for now and focus on the URL management flow. Auth can be added as middleware."

Technique 3: Eliminate by Impact

"The primary use case is read-heavy redirects. I'll optimize for that and handle writes efficiently but not prioritize them."

Scoping Anti-Patterns to Avoid

• ❌ Trying to design every feature mentioned
• ❌ Asking too many clarification questions (> 5)
• ❌ Not confirming scope with the interviewer
• ❌ Making assumptions without stating them
• ❌ Skipping non-functional requirements entirely

Real Interview Examples

Below are actual system design prompts and the clarification questions top candidates ask.

Example 1: Design Twitter

Prompt: "Design a simplified version of Twitter."

Clarification Questions:

SCALE QUESTIONS
• "Are we designing for 300M DAU or a smaller product?"
• "What is the tweet volume? ~500M tweets/day?"
• "Read-to-write ratio? Probably 100:1 with heavy timeline reads?"

FEATURE QUESTIONS
• "Should tweets support media (images, videos) or just text?"
• "What is the maximum tweet length? 280 characters?"
• "Do we need to support replies, retweets, and likes?"
• "Is the timeline chronological or algorithmic (ranked)?"

NON-FUNCTIONAL QUESTIONS
• "Timeline latency? Under 1 second?"
• "Is eventual consistency acceptable for follower counts?"
• "Do we need to handle trending topics or hashtags?"

SCOPE DECISION
"I'll focus on: posting tweets, following users, and generating a timeline feed.
We can discuss search and trends if time permits."

Example 2: Design a Chat System

Prompt: "Design WhatsApp."

Clarification Questions:

SCALE QUESTIONS
• "1:1 chat only, or also group chats?"
• "Max group size? 100 or 1000?"
• "How many messages per day? 100 billion?"

FEATURE QUESTIONS
• "Do we need message delivery receipts (sent, delivered, read)?"
• "End-to-end encryption required?"
• "Support media sharing (images, video, voice)?"
• "Offline message delivery?"

NON-FUNCTIONAL QUESTIONS
• "Message latency requirement? Under 200ms?"
• "Message ordering guaranteed?"
• "Message retention policy? Forever or time-limited?"

SCOPE DECISION
"I'll focus on 1:1 messaging with delivery receipts. Group chat and media
sharing are extensions we can discuss."

Example 3: Design a URL Shortener

Prompt: "Design a URL shortening service."

Clarification Questions:

SCALE QUESTIONS
• "How many new URLs per day? 100M?"
• "What is the read-to-write ratio? 10:1? 100:1?"
• "Is global or regional?"

FEATURE QUESTIONS
• "Do we need custom aliases?"
• "Link expiration?"
• "Analytics (click count, geo, referrer)?"
• "Can users manage (delete/edit) their URLs?"

NON-FUNCTIONAL QUESTIONS
• "Redirect latency? Under 100ms?"
• "URL cannot be predictable/guessable?"
• "Availability requirement? 99.99%?"

SCOPE DECISION
"I'll design core URL creation and redirection with basic analytics.
Custom aliases and user management are P1 features."

Common Mistakes Candidates Make

Mistake	Why It Hurts	Fix
Skipping requirements entirely	Shows lack of structured thinking	Always ask 3-5 questions
Asking too many questions (> 7)	Wastes time, shows indecision	Limit to 4 questions max
Not confirming scope	May design the wrong system	Summarize scope in 1 sentence
Making unspoken assumptions	Confuses interviewer	State every assumption aloud
Only asking functional questions	Ignores critical constraints	Mix scale, latency, consistency
Asking about implementation details	"What database should I use?"	Focus on requirements, not tech

The Confirmation Pattern

After asking questions, always confirm with the interviewer:

"Let me summarize what I've understood:

1. We're building a [SYSTEM] for [USER BASE]
2. Expected scale: [TRAFFIC NUMBERS]
3. Core features: [LIST 2-3 FEATURES]
4. Key constraints: [LATENCY/CONSISTENCY]

Does this align with your expectations?"

This demonstrates clarity of thought and gets buy-in before you start designing.