Scoping the problem

TL;DR

• Scoping is the single most important first step in any system design interview. Get it wrong and you spend 40 minutes designing the wrong system.
• Use the WHO/WHAT/HOW MUCH/WHAT CONSTRAINTS framework to turn a vague prompt into a focused build plan in under 5 minutes.
• Functional requirements define what the system does. Non-functional requirements define how well. Separate them explicitly before designing anything.
• The "core user journey" technique (trace one request end-to-end) anchors every architecture decision to a real user action.
• Scoping is about saying NO. The features you exclude matter more than the ones you include, because exclusions prevent scope creep that kills your interview.

The Wrong System, Perfectly Designed

You're 12 minutes into a "Design Twitter" interview. You've drawn a beautiful microservices architecture with a notification service, a search service, a trending algorithms pipeline, and an ad-serving layer. The interviewer leans forward: "I actually wanted us to focus on the home timeline read path."

You've spent a quarter of your interview designing four systems you won't discuss. Now you're scrambling to pivot, erasing boxes, redrawing arrows, and the interviewer is writing "poor scoping" in their notes.

I've seen this happen at every level, from junior to staff. The root cause is always the same: the candidate started drawing before they started asking. They treated "Design Twitter" as a complete specification instead of what it actually is, an intentionally vague prompt designed to test whether you can scope.

The fix is simple but counterintuitive. Spend the first 3 to 5 minutes doing almost nothing visible. Ask questions. Write down requirements. Say what you're NOT building. Only then pick up the marker.

The Scoping Framework: WHO / WHAT / HOW MUCH / WHAT CONSTRAINTS

Every system design prompt can be decomposed with four questions. I use this framework every single time, whether the prompt is "Design Uber" or "Design a URL shortener." It takes 3 to 5 minutes and prevents the wrong-system problem entirely.

WHO uses it?

This question reveals the user types and access patterns. "Design a file storage system" means something completely different for consumers (Dropbox) versus enterprises (S3).

Questions to ask:

• "Who are the primary users? End consumers, internal teams, or other services?"
• "Are there different user roles with different access patterns?"
• "Is this a B2C product with millions of users or a B2B tool with thousands of tenants?"

WHAT do they do?

This is where you define functional requirements. You're looking for the 2 to 4 core operations that the system must support. Not 10. Not 15. Two to four.

Questions to ask:

• "What are the core user actions? Let me name 2 to 3 and confirm."
• "Are we designing the write path, the read path, or both?"
• "Which specific feature should I focus on?"

HOW MUCH scale?

Scale changes everything about your architecture. A system handling 100 requests per second needs a completely different design than one handling 100,000.

Questions to ask:

• "What's the expected number of daily active users?"
• "What's the peak read/write ratio?"
• "How much data are we storing, and what's the growth rate?"

WHAT constraints exist?

Constraints are the non-functional requirements that force specific architecture decisions. Latency targets, consistency requirements, availability SLAs.

Questions to ask:

• "Is availability or consistency more important for this feature?"
• "What latency is acceptable? Sub-100ms or is a few seconds okay?"
• "Are there regulatory constraints (GDPR, HIPAA, PCI)?"

For your interview: write these four categories on the whiteboard or shared doc before asking your first question. It signals structure and gives the interviewer confidence that you have a process.

Functional vs Non-Functional: Separate Them Early

One of the clearest signals of a structured thinker is explicitly separating functional requirements (what the system does) from non-functional requirements (how well it does it). Most candidates mash them together. Don't.

Functional requirements answer: "What can users do?"

• Post a tweet
• View their home timeline
• Follow/unfollow users

Non-functional requirements answer: "How well does it perform?"

• Timeline loads in under 200ms at P99
• 99.99% availability
• Eventual consistency acceptable for timeline (5-second staleness okay)

The reason separation matters is that the same functional requirement produces completely different architectures depending on the NFRs. "User posts a tweet" with 1,000 users per day is a single PostgreSQL insert. "User posts a tweet" at 100,000 tweets per second with sub-100ms fan-out needs Kafka, pre-computed timelines, and a push/pull hybrid model.

I always write two columns on the whiteboard: "Functional" on the left, "Non-Functional" on the right. Then I fill them in from my scoping questions.

The Core User Journey Technique

After scoping, you need a north star that anchors every architecture decision. The technique I use: trace one request end-to-end through the system before designing anything.

Pick the most important user action (usually the primary read path) and walk through every step from the user's perspective. This isn't architecture yet. It's a narrative.

Here's what it looks like for "Design Twitter, home timeline":

Core User Journey: View Home Timeline

1. User opens the app
2. Client sends GET /timeline?cursor=<last_seen>
3. System retrieves tweets from people the user follows
4. Tweets are ranked/sorted (chronological or algorithmic)
5. Response includes tweet content, author info, engagement counts
6. Client renders the timeline with infinite scroll

Key question at each step:
  - Step 3: How do we assemble the timeline? Pre-computed or on-the-fly?
  - Step 4: Is ranking required or is chronological enough?
  - Step 5: How fresh must engagement counts be?

This technique does three things at once. First, it validates your functional requirements (if the journey doesn't match the requirements, you missed something). Second, it surfaces design questions naturally (each step raises a "how" question). Third, it gives you a thread to follow when you start drawing architecture.

My recommendation: write the core user journey as a numbered list on the whiteboard. It takes 60 seconds and it becomes the skeleton of your flow design.

Scoping Is About Saying NO

This is the part most candidates struggle with. Scoping isn't just about what you include. It's about what you explicitly exclude, and how you communicate those exclusions.

A common failure mode: the candidate says "I'll design everything" or silently assumes they need to cover every feature. Thirty minutes later, they have a shallow sketch of 8 services and depth on nothing. The interviewer's notes say "breadth without depth."

The antidote is explicit exclusion. Name what you're NOT designing and explain why.

How to exclude gracefully:

Bad: ignoring features silently

Bad: "I won't do search because it's hard."

Good: "I'm going to set search, trending, and DMs as out of scope for now so we can go deep on the timeline read and write paths. I can circle back to search if we have time. Does that work?"

That last phrasing does three things: it names the exclusions, it explains the tradeoff (depth over breadth), and it gives the interviewer a chance to redirect.

The scope boundary checklist:

For most prompts, you should explicitly address whether these are in or out:

• Authentication/authorization (usually out, assume it exists)
• Admin/moderation tools (usually out)
• Analytics and monitoring (usually out, mention it in passing)
• Payment/billing (out unless it's the core prompt)
• Search (out unless it's the core prompt)
• Notifications (depends, clarify)

Worked Example: Scoping "Design Twitter"

Let's walk through the full scoping process for the most common system design prompt. This is exactly what the first 4 to 5 minutes should look like.

Step 1: WHO uses it?

"I'm assuming this is the consumer-facing Twitter product, not the internal analytics platform or the ads system. Users are end consumers who read and write tweets. There are also 'celebrity' users with millions of followers whose access patterns are different from regular users. Can you confirm?"

Interviewer: "Yes, consumer-facing. Good call on celebrities."

Step 2: WHAT do they do?

"The core operations I want to focus on:

1. User posts a tweet (write path)
2. User views their home timeline, i.e., tweets from people they follow (read path)

I'm going to set search, trending, DMs, notifications, and ads as out of scope so we can go deep on the timeline. Does that work?"

Interviewer: "That's fine. Let's focus on timeline."

Step 3: HOW MUCH scale?

"Let me assume Twitter-scale numbers:

• 500M DAU
• Average user follows ~200 people
• ~500M tweets per day, roughly 6,000 tweets per second average, with peaks at 50,000 to 100,000
• Read-heavy: maybe 100:1 read-to-write ratio for timeline views
• Timeline request volume: billions per day

Does that feel right, or should I use different numbers?"

Interviewer: "Those are reasonable."

Step 4: WHAT constraints?

"For non-functional requirements:

• Availability: 99.99% (users expect Twitter to always work)
• Latency: P99 under 200ms for timeline reads
• Consistency: Eventual consistency is fine. A 5-second delay before a tweet appears in followers' timelines is acceptable.
• Durability: Tweets must never be lost once acknowledged

So I'll optimize for availability and low-latency reads over strict consistency."

Step 5: Confirm and proceed

"Let me summarize the scope:

• We're designing the tweet write path and home timeline read path
• 500M DAU, 100K tweets/sec peak, 100:1 read/write ratio
• Optimize for availability and latency, accept eventual consistency
• Search, trending, DMs, auth are out of scope

Sound good?"

Interviewer: "Perfect. Let's proceed."

Total time: 4 minutes. Every subsequent architecture decision now has a clear justification. The Redis pre-computed timeline? That's because of the 200ms P99 latency target. The Kafka fan-out? That's because of the 100K tweets/sec throughput and eventual consistency acceptance.

Common Mistakes

Jumping to architecture before scoping. "I'll use Kafka and Redis and Postgres" is not a design. It's a shopping list. You haven't defined what you're building yet. I've seen candidates draw three microservices in the first 90 seconds without asking a single question.

Over-scoping: trying to design the entire product. "Design Twitter" does not mean design search, trending, DMs, ads, analytics, and the recommendation engine. Pick 2 to 3 core operations and go deep. Breadth without depth fails every time.

Under-scoping: designing something trivial. "I'll design a basic CRUD API for tweets" is too narrow. You've avoided the interesting architectural challenges (fan-out, timeline assembly, scale) that the interviewer wants to discuss.

Not confirming scope with the interviewer. You ask great questions, form a mental model, and then start designing without restating your conclusions. The interviewer may have a different understanding. Always confirm before proceeding.

Treating scoping as a one-time event. Scope can shift during the interview. If the interviewer says "what about search?" midway through, that's a signal to discuss a scope extension, not a sign that your original scoping was wrong. Acknowledge it, decide whether to incorporate it, and keep moving.

How This Shows Up in Interviews

The first 3 to 5 minutes of every system design interview is a scoping test, whether the interviewer frames it that way or not. Here's what they're looking for at each level.

What interviewers evaluate during scoping:

Common follow-up questions from interviewers:

A Quick Scoping Checklist

Before moving to API design, check that you've covered each of these. If you can't answer any of them, you need to ask more questions.

Quick Recap

1. Scoping is the first and most important step in every system design interview. Spend 3 to 5 minutes on it, not zero, not eight.
2. Use the WHO/WHAT/HOW MUCH/WHAT CONSTRAINTS framework to decompose any vague prompt into concrete requirements.
3. Separate functional requirements from non-functional requirements explicitly. NFRs drive architecture, features don't.
4. Trace one core user journey end-to-end before designing anything. This becomes the skeleton of your flow design.
5. Scoping is about saying NO. Name what you're excluding, explain the tradeoff (depth over breadth), and confirm with the interviewer.
6. Always confirm scope before proceeding. One sentence: "Here's what I'm building and here's what I'm not. Does that align?"
7. The right scope is specific enough to go deep and narrow enough to finish. "Design the Twitter home timeline read path" is right. "Design Twitter" is too broad.