Skip to main content

Understanding the Requirements

What This Concept Is​

A system design problem never comes fully specified. The first job is not to draw boxes. It is to convert a vague prompt into three separate, explicit lists:

  • Functional requirements: what the system must do, in verbs the user would recognize. "Users can post a tweet", "followers see new tweets in their feed", "a tweet can be deleted".
  • Non-functional requirements: measurable properties the system must hold. "Feed load P99 under 200 ms", "99.9% availability", "read:write ratio around 100:1", "survive one AZ outage without downtime".
  • Constraints: hard limits the environment imposes. "Mobile clients on flaky networks", "regulatory requirement to store posts for 7 years", "budget for at most 50 machines", "must fit in the existing AWS account".

These are three different conversations. Mixing them is the most common framing failure.

In the Richards & Ford vocabulary these non-functional items are architecture characteristics -- the -ilities (availability, scalability, elasticity, recoverability, auditability). They are what decides the shape of the architecture, while functional requirements decide only its surface. A feature list that omits architecture characteristics is not a specification; it is a wish list. Your job in framing is to surface the two or three characteristics that dominate, because those are the ones that will bend every later decision.

The method is not "gather every requirement that could ever apply". It is "gather the minimum set the design must push against", then confirm with the interviewer or stakeholder. Anything not on the list is explicitly deferred, not quietly assumed.

Why It Matters Here​

Every later decision in the method is downstream of this list.

  • Cluster 1 estimation uses the non-functional numbers (QPS, latency, availability) to size the system.
  • Cluster 2 storage and caching choices depend on the read:write ratio and the consistency requirements.
  • Cluster 3 data model depends on the access patterns implied by the functional list.
  • Cluster 4 stress tests assume the numbers are real.
  • Cluster 5 trade-offs only make sense when the requirement being traded against is named.

If you skip this step, you end up defending a design against requirements the interviewer never agreed to.

Concrete Example​

Prompt: "Design a URL shortener."

Bad framing (what most candidates do):

"Okay, so we need a database to store URLs and a hash function..."

Good framing (ten minutes, out loud):

Functional:

  1. Given a long URL, return a short URL.
  2. Given a short URL, redirect to the long URL.
  3. Optional: custom aliases, expiration, per-user analytics.

Non-functional (with numbers I will propose and confirm):

  • 100 million new short URLs per month.
  • Read:write ratio roughly 100:1.
  • Redirect P99 latency under 100 ms.
  • 99.9% availability.
  • Short URLs are permanent (deletion is explicit, not time-based).

Constraints:

  • URLs must be short enough to fit in SMS (let's aim for 7 characters).
  • Must not leak a predictable sequence (no incrementing integers in the URL).
  • Write path can be async-ish; read path cannot.

Now every later decision has something to push against. "Should we use a SQL database?" becomes answerable: 100M/month is 40 writes/sec average, reads around 4,000/sec; that is small; SQL is fine; the real question is how to avoid hot keys and how to scale the read path with cache.

Concrete Example 2: Chat System​

Prompt: "Design a chat system like WhatsApp." The same framing move, applied:

Functional: 1-on-1 messaging; group chat up to 100 members; typing indicators; read receipts; message history retrievable on new device login; image attachments; push notifications to offline recipients.

Non-functional (proposed and confirmed): 500 M DAU; 40 messages/user/day; message send P99 under 500 ms end-to-end; delivery guarantees at-least-once, with client-side de-duplication; history durability 1 year hot, 5 years cold; 99.95% availability on send.

Constraints: mobile-first on unreliable networks; must work across iOS, Android, web; end-to-end encryption for 1-on-1 (regulatory in some regions); battery-aware protocol on mobile.

The dominant non-functional here is delivery semantics + latency under poor networks -- very different from the URL shortener's dominant non-functional (cheap, cached reads). Same methodology, completely different design pressure, and you have said so out loud before drawing a box.

Common Confusion / Misconceptions​

"Non-functional means unimportant." The opposite. Functional requirements tell you which features to build; non-functional requirements tell you which architecture to build. A feature list is the same for a prototype and a production system. The non-functional numbers are what make them different designs.

"We will figure out the numbers later." The numbers are the design. "10 QPS" and "10 million QPS" produce completely different systems, even if the features are identical. State the numbers early; confirm them with the interviewer; write them on the board.

"Requirements are the interviewer's job." The interviewer is deliberately vague. You are being tested on whether you ask. Silence means "I assumed and will now defend an arbitrary design".

"Every architecture characteristic matters equally." It does not. Richards & Ford insist that architects explicitly rank characteristics. If every -ility is a top-three priority, nothing is, and the design collapses under conflicting optimization. Pick the two or three that dominate this problem and say what you deprioritized.

How To Use It​

Open every design with a five-step move:

  1. Restate the prompt in one sentence. "You want a system that lets users shorten long URLs and later redirect to them, used by millions, globally."
  2. Ask for functional scope. List features; ask which are in and out. Write them on the board.
  3. Ask for scale. Users, QPS, data size, read:write ratio. If the interviewer says "you pick", propose a number and confirm.
  4. Ask for targets. Latency, availability, durability, consistency. Be specific: "P99 under 200 ms" not "fast".
  5. Ask for constraints. Platform, regulatory, budget, existing systems.

Write each answer down. This is your contract with the interviewer for the rest of the session.

Transfer / Where This Shows Up Later​

This framing template appears almost verbatim in every later module:

  • S8M2 (microservices) uses the same characteristic-ranking to decide service boundaries -- "this service is latency-critical, that one is consistency-critical".
  • S8M4 (scale/reliability/performance) is entirely organized around non-functional characteristics from this step; the SLOs you define here become SLOs you operate against there.
  • S8M5 (technical leadership) treats this list as the input to ADRs and architectural reviews; the S7M5 ADR template has a dedicated "requirements being traded against" field for exactly this reason.
  • S9 (cloud + DevOps) maps these characteristics to cloud services -- availability targets translate to multi-AZ/multi-region configurations; latency targets translate to edge/CDN placement; durability translates to backup/restore tiers.
  • S10 capstone + interview practice: the opening five minutes of every system-design interview are this exact move. Candidates who cannot run it reliably fail before the box diagram.

Check Yourself​

  1. Name one requirement that would force you to choose a strongly consistent database, and one that would force you to choose an eventually consistent one.
  2. Is "99.99% availability" a functional or non-functional requirement? What about "users can delete their account within 30 days"?
  3. Why is "read:write ratio" a non-functional requirement and not a constraint?
  4. For a chat system, which two architecture characteristics dominate, and which one did you deprioritize to get there?

Mini Drill or Application​

For each prompt, produce in five minutes a written list of 3-5 functional requirements, 3 non-functional numbers, and 3 constraints:

  1. Design a ride-sharing backend.
  2. Design a distributed rate limiter for an API gateway.
  3. Design a real-time stock price feed for a retail trading app.
  4. Design a cloud photo backup service.

For each, circle the one non-functional number that most shapes the design. Then for each, state explicitly which two characteristics dominate and which one you deliberately deprioritized.

Read This Only If Stuck​