system-design

Requirements Gathering: The Questions to Always Ask

The phase where interviews are won and lost. Ten minutes of the right questions turns a vague prompt into a scoped, designable problem — and demonstrates the judgment interviewers are actually grading.

Prerequisites: The Framework Time to read: ~16 minutes

Why this phase decides the outcome

🚨 “Design Instagram” is deliberately vague, and that’s the test. The interviewer wants to see whether you’ll scope the problem before solving it, or charge ahead building the wrong thing. A candidate who spends 30 seconds and starts drawing has already signaled inexperience; one who asks sharp clarifying questions has signaled the opposite.

The goal of this phase: turn an unbounded prompt into a specific, bounded, designable problem, and extract the non-functional requirements that will drive every subsequent decision.

🎙️ “Before I design anything, I have some clarifying questions — the scale and consistency needs will shape the whole approach.”

Functional requirements: what does it do?

Establish the core features and — crucially — cut the scope.

The questions:

“What are the core use cases? For Instagram: posting photos, viewing a feed, following users?”
“Is [X] in scope?” (stories, DMs, search, ads, live video) — 🚨 propose cutting most of them.
“Who are the users? What’s the primary action?”

🚨 Aggressively narrow, and state what’s out of scope explicitly:

“I’ll focus on the core: posting photos and viewing a home feed. I’ll treat stories, DMs, search, and ads as out of scope — I’ll note where they’d plug in, but I want to design the core well rather than sketch everything shallowly. Does that work?”

Why cutting scope is a strength, not a weakness: it shows judgment (you know what matters), it buys time to go deep (which is what’s graded), and it prevents the “designed everything shallowly, nothing well” failure. Interviewers respect a candidate who scopes.

Non-functional requirements: the ones that drive the architecture

🚨 These matter more than the features, because they determine the whole design. Ask about each:

Scale

“How many users? Daily active? Requests per second? Data volume?”
If they don’t give numbers, propose them: “Let’s assume 500M users, 100M daily active — does that sound right?”
🚨 This feeds directly into estimation.

Read/write ratio

🚨 Always ask this. “What’s the read/write ratio?” A 100:1 read-heavy system (most social apps) and a write-heavy one are completely different designs. → Scaling Reads

Latency

“What’s the latency requirement? Is 200ms acceptable, or does the feed need to load in 50ms?”
Latency targets change everything — precomputation, caching depth, geographic distribution.

Availability

“How available does this need to be? Three nines, four nines?”
“What’s the cost of downtime — is this a payment system or a photo feed?”

Consistency

🚨 “Where does consistency matter? Can the feed be slightly stale, or does it need to be up-to-the-second? What about like counts?”
This is a per-feature question — the feed can be eventually consistent, but the payment can’t.

Durability

“Can we ever lose data? A dropped like is fine; a lost payment isn’t.”

The universal question checklist

🚨 A checklist you can apply to almost any design prompt:

FUNCTIONAL
□ What are the core use cases? (and what's OUT of scope?)
□ Who are the users and what's the primary action?

SCALE
□ How many users / DAU?
□ Requests per second (read and write)?
□ Read/write ratio?
□ Data volume and growth?

QUALITY
□ Latency target?
□ Availability target (nines)?
□ Consistency needs (per feature)?
□ Durability needs?

CONTEXT
□ Any specific constraints? (mobile, offline, real-time, global, regulated)
□ Existing systems to integrate with?

You won’t ask all of these — pick the ones that matter for the specific problem — but having the checklist means you never miss the architecture-defining ones (scale, read/write ratio, consistency).

Reading between the lines

🚨 Some requirements are implied and worth surfacing:

“Real-time” → WebSockets/push, stateful connections, the delivery problem.
“Global users” → multi-region, geo-latency, data residency.
“Photos/video” → object storage + CDN, large bandwidth.
“Payments/money” → strong consistency, idempotency, audit, no data loss.
“Social/feed” → fan-out, the celebrity problem, read-heavy.
“Search” → inverted index, a search engine, relevance.

Naming these implications when you hear the keyword shows you connect requirements to architecture.

Turning requirements into design constraints

🚨 The payoff: each requirement becomes a design decision. Don’t just collect requirements — use them:

“Read/write is 100:1 → design for reads: cache and precompute.”
“Feed can be eventually consistent → we can cache aggressively and use replicas.”
“500M users, 100M DAU → this is definitely at sharding/distributed scale.”
“Photos → object storage + CDN, not the database.”
“Global → multi-region eventually.”

🎙️ “So: read-heavy, eventual consistency is fine for the feed, hundreds of millions of users, and photos. That tells me to design for reads with heavy caching and precomputation, store media in object storage behind a CDN, and shard the metadata. Let me estimate to confirm the scale.”

This transition — from requirements to a design strategy — is the whole point of the phase.

Time management

🚨 Spend ~5-8 minutes here, no more. The failure mode is spending 20 minutes gathering requirements and never reaching a design. Ask the architecture-defining questions (scale, read/write, consistency), scope aggressively, and move on. You can always revisit a requirement during the design.

🚨 Interview traps

Skipping requirements and jumping to design.
Not scoping — trying to design everything.
Not asking the read/write ratio, scale, or consistency needs — the architecture-defining ones.
Collecting requirements but not using them to drive the design.
Spending too long — 20 minutes of requirements, no design.
Not stating what’s out of scope.

🎙️ Soundbites

“Before designing, let me clarify scope and the non-functional requirements — those shape the whole approach. What’s the scale, the read/write ratio, and where does consistency matter?”
“I’ll scope aggressively: the core is posting and the feed. I’ll treat DMs, search, and ads as out of scope and note where they’d plug in, so I can design the core well rather than sketch everything shallowly.”
“Can the feed be slightly stale? If eventual consistency is acceptable there, I can cache aggressively and use replicas — that’s a big simplification.”
“So it’s read-heavy, eventually consistent, hundreds of millions of users, with photos. That tells me to design for reads with caching and precomputation, media in object storage behind a CDN, and shard the metadata. Let me confirm with estimation.”

🛠️ Try it

1. Generate the questions for ten prompts. For ten different “Design X” prompts, write down the clarifying questions you’d ask — functional (scope) and non-functional (scale, read/write, latency, consistency). Do it fast, from the checklist. The goal is to make the questioning automatic.

2. Practice scoping out loud. For each prompt, state the scope decision: “I’ll focus on X and Y, and treat Z as out of scope.” Practice making the cut confidently — hesitant scoping reads as uncertainty.

3. Turn requirements into constraints. For a prompt, gather the requirements, then explicitly state what each one implies for the design (“read-heavy → cache; photos → object storage”). This requirements-to-design transition is the phase’s payoff — practice making it explicit.

4. Time yourself. Do the requirements phase for a case study with a 6-minute timer. If you’re not done in 6-8 minutes, you’re over-gathering — practice hitting the architecture-defining questions and moving on.

Check yourself

1. Why is aggressively cutting scope a strength rather than a weakness in a design interview?

Because the prompt is deliberately unbounded ("Design Instagram" encompasses posting, feeds, stories, DMs, search, ads, live video, and more), and you cannot design all of it well in 45 minutes — so attempting to means sketching everything shallowly and demonstrating nothing deeply, which is exactly what fails. Cutting scope to the core (posting and the feed) and *explicitly stating* what you're excluding shows three things the interviewer is grading: **judgment** (you can identify what matters most versus what's peripheral), **communication** (you set clear expectations and get agreement rather than silently narrowing), and **time awareness** (you're allocating the limited time to depth on the core rather than breadth across everything). It also directly enables the deep-dive phase where seniority is demonstrated — you can only go three levels deep on the feed if you're not trying to also design search and ads. Far from looking like you're avoiding work, decisive scoping ("I'll focus on X and Y, treat Z as out of scope and note where it'd plug in") looks like someone who has run real design reviews and knows that a well-designed core beats a shallow sketch of everything. Interviewers consistently reward it.

2. Which non-functional requirements are most important to establish, and why?

Scale, read/write ratio, latency, availability, consistency, and durability — with scale, read/write ratio, and consistency being the most architecture-defining. They matter more than the *features* because the same feature is a completely different system depending on them: a photo feed and a trading system might both be "show a stream of items," but one tolerates seconds of staleness and the other needs microseconds and strict correctness. **Scale** (users, QPS, data volume) determines whether you need one database or a sharded distributed system — a huge difference. **Read/write ratio** determines the whole strategy: a 100:1 read-heavy system (most social apps) is designed around caching, replicas, and precomputation, while a write-heavy one needs batching, async, and write-optimized storage — so you *always* ask this. **Consistency** is a per-feature question that decides where you can cache and use eventual consistency (the feed, like counts) versus where you need strong consistency (payments, inventory), and getting it wrong means either an over-engineered system or a correctness bug. Latency, availability, and durability similarly constrain the design (precomputation and geo-distribution, number of nines and redundancy, whether you can ever lose data). Establishing these up front means your design is *derived* from real constraints rather than guessed, which is both correct and a strong signal.

3. How do you turn gathered requirements into design decisions, and why is that the point?

By explicitly stating what each requirement *implies* for the architecture, rather than just collecting them and moving on. Each non-functional requirement maps to a concrete design choice: "read/write is 100:1" implies "design for reads — cache aggressively, add read replicas, precompute expensive views"; "the feed can be eventually consistent" implies "we can serve from caches and replicas without worrying about staleness"; "500M users, 100M DAU" implies "this is at distributed/sharding scale, not single-database"; "photos" implies "object storage behind a CDN, not blobs in the database"; "global users" implies "multi-region eventually." That transition — from a list of requirements to a coherent design strategy — is the point of the requirements phase because requirements aren't collected for their own sake; they exist to *constrain and direct* the design. A candidate who gathers requirements and then designs something disconnected from them has wasted the phase; one who says "so, given it's read-heavy, eventually consistent, at hundreds of millions of users, with photos, I'll design for reads with heavy caching, store media in object storage behind a CDN, and shard the metadata" has shown that their design is *derived* from the problem rather than pattern-matched from memory. This makes every subsequent decision justifiable ("I'm caching here *because* we established it's read-heavy"), which is exactly the reasoning-not-reciting behaviour that scores. The requirements phase and the design phase are connected by this act of translation.

4. What does it mean to "read between the lines" of a prompt, and why does it help?

It means recognizing that certain words in a prompt carry implicit technical requirements, and surfacing them proactively. When a prompt says "real-time," it implies persistent connections (WebSockets/SSE), stateful servers, and the server-push routing problem; "global users" implies multi-region deployment, geo-latency, and data-residency compliance; "photos/video" implies object storage, CDN, and large bandwidth (not database blobs); "payments" implies strong consistency, idempotency, an audit trail, and no tolerance for data loss; "social feed" implies fan-out, the celebrity/hot-key problem, and a read-heavy profile; "search" implies an inverted index and relevance ranking. Reading between the lines helps because it demonstrates that you connect problem descriptions to architectural consequences — the core skill being tested — and it lets you get ahead of the design ("since this is real-time, I'll need to solve message delivery, so I'll plan for WebSockets and a connection-to-server routing layer"). It also surfaces requirements the interviewer may not have stated explicitly but expects you to identify, and addressing them unprompted (rather than being led to them) signals experience. The candidate who hears "design a payment system" and immediately flags idempotency and strong consistency, or hears "global" and raises multi-region and residency, shows they understand what these categories of system actually require — which is more impressive than waiting to be asked.

5. How much time should requirements take, and what's the failure mode of getting it wrong?

About 5-8 minutes of a 45-minute round — enough to scope the problem and extract the architecture- defining non-functional requirements (scale, read/write ratio, consistency, latency, availability), but not more. There are two opposite failure modes. **Under-investing** (30 seconds, then charging into design) means you design the wrong system — you miss that it's write-heavy, or that consistency matters somewhere critical, and your whole architecture is misdirected; it also signals inexperience, since skipping straight to boxes is what junior candidates do. **Over-investing** (spending 20 minutes meticulously gathering every requirement) is the more insidious failure: you run out of clock and never reach an actual design, or reach it with no time for the deep dives where seniority is demonstrated — so you leave the interviewer with a well-scoped problem and no solution, which reads as poor time management and prevents you from showing your technical depth. The discipline is to ask the *few* questions that actually change the architecture (scale, read/write, consistency — not every edge case), scope aggressively and explicitly, translate the requirements into a design direction, and move on, knowing you can revisit a specific requirement later when the design raises it. The clock is the constraint that makes this a skill: gathering requirements is necessary, but it's the setup for the design, not the main event.