Requirements & Estimation

The Delivery Framework tells you to start with requirements and estimation. But knowing *that* you should do it and knowing *how* to do it well are very different things. Most candidates either rush through requirements in 60 seconds or spend 15 minutes producing a grocery list that doesn't guide any design decisions.

This lesson teaches you how to do both steps well. You'll learn to scope a problem so your design has clear boundaries, and to estimate only when the numbers change what you build.

Functional Requirements

Functional requirements define what the system does, the user-facing capabilities. In an interview, you're not trying to capture every feature. You're trying to identify the 3-4 core capabilities that define the system and scope your design.

How to Frame Them

Always use the format: "Users should be able to..." This keeps requirements grounded in user actions rather than implementation details. "Users should be able to post short text messages" is a functional requirement. "The system uses a write-ahead log for tweet ingestion" is not. That's an implementation detail masquerading as a requirement.

Discuss requirements conversationally with the interviewer, as a back-and-forth rather than a monologue. Ask scoping questions as you go: "Should users be able to edit tweets after posting?" "Do we need to support media attachments or just text?" Each question shows you're thinking about product trade-offs alongside the technical ones.

Prioritize Ruthlessly

The single biggest mistake in requirements gathering is listing too many. Every requirement you add is a commitment to design, explain, and defend. Four focused requirements are far better than eight vague ones.

How do you choose which 3-4 to focus on? Pick the ones that make this system this system and not something generic. For a URL shortener, the interesting requirements are shortening, redirecting, and maybe analytics. User authentication isn't one of them. For a chat app, it's real-time messaging, group conversations, and delivery receipts, never profile editing.

Worked Example

Consider "Design Dropbox." Notice how the strong version focuses on what makes Dropbox unique, rather than listing everything a file storage app could do.

The weak version lists eight features but fails to identify what makes Dropbox *Dropbox*: large file handling, multi-device sync, and sharing. The strong version scopes the problem to three capabilities that drive every major architecture decision.

Non-Functional Requirements

Non-functional requirements (NFRs) define the qualities your system must have: performance, reliability, consistency, scale. These are the constraints that shape your architecture. Frame them as "The system should..." statements.

Here's the key difference between weak and strong NFRs. Weak NFRs are generic ("the system should be scalable"), while strong NFRs are specific to this problem and directly influence a design choice.

The NFR Categories That Matter

Not all NFR categories apply to every problem. Pick the 2-3 that create the most architectural tension for your specific system.

Worked Example

Capacity Estimation

Capacity estimation, also called "back-of-envelope math," is the most over-practiced and misunderstood part of the system design interview. Candidates spend valuable minutes calculating exact QPS, storage requirements, and bandwidth numbers, then never reference those numbers again.

When to Estimate

Estimate only when a number changes a design decision. If the answer is "we need a database" regardless of whether you have 1M or 100M users, the estimation adds no value.

When you do estimate, tell the interviewer why: "Let me check whether a single machine can handle this workload, because it changes whether I need to shard." That framing shows mature engineering judgment rather than rote calculation.

How to Estimate Quickly

When estimation is warranted, keep it fast. You're looking for order-of-magnitude answers. Round aggressively and state your assumptions out loud.

A reliable formula for traffic estimation: start with DAU, estimate the percentage that performs the relevant action, and convert to per-second rates. For storage: estimate the average size of one record, multiply by the number of records per day, then extrapolate.

Notice the shortcut: instead of dividing by 86,400 seconds in a day, use 100K (10⁵). This is close enough for interview math and much easier to compute mentally. Similarly, use 1M seconds per ~10 days, and 30M seconds per month.

Useful Numbers to Memorize

You don't need to memorize a giant table of latencies and throughput numbers. A handful of reference points make estimation dramatically faster.

• ~100K Seconds per day. Actually 86,400; round up.
• ~1 KB Avg text record. A tweet, comment, or short message.
• ~1 MB Avg image. After compression (JPEG).
• ~10 MB Avg video minute. Compressed, standard quality.
• ~10K SQL reads/sec. Single PostgreSQL instance.
• ~100K Redis ops/sec. Single Redis instance.

These are ballpark figures. The exact numbers depend on hardware, configuration, and query complexity. But they give you enough precision to make design decisions, which is all that matters.

The "Defer" Strategy

Here's the approach that top candidates use: during the requirements phase, state your scale assumptions ("I'll assume 100M DAU, read-heavy workload") but don't do the math yet. Instead, say: "I'll estimate specific numbers when they become relevant to a design decision."

Then, during high-level design or deep dives, when you reach a decision point, pull out the estimation: "Should I precompute the feed or generate it on demand? Let me estimate the fanout..." This approach uses your time far more efficiently and makes your estimations feel purposeful rather than performative.

Putting It All Together

Here's what the first five minutes of a well-executed system design interview looks like, applied to "Design a URL Shortener."

Total time: five minutes. The interviewer now knows exactly what system you're building, what constraints you're designing for, and that you have a plan for when to dive into numbers. You've demonstrated problem navigation without wasting a minute on unnecessary math.

Common Mistakes

"The system should be scalable, reliable, and fast." Those are not non-functional requirements. They're adjectives. Every system should be all three. Your NFRs need to specify *how* scalable, *how* reliable, and *how* fast, and *why* those targets matter for this particular system.

Listing requirements you won't design for. If you say "users should be able to search tweets" but then never design a search component, the requirement just highlighted a gap. Only state requirements you intend to address.

Spending 5 minutes on capacity estimation at the start. Unless a number changes your design, those 5 minutes are better spent on high-level architecture. Most interviewers would rather see a complete design than precise QPS figures.

Not involving the interviewer. Requirements should be a conversation. If you spend three minutes in a monologue listing requirements, you've missed the chance to demonstrate collaboration and to get the interviewer's guidance on what they care about most.