Functional vs Non Functional Requirements | Questions to ask
Every system design interview opens the same way: a vague prompt, and a few minutes to turn it into a scoped problem by asking questions. Those questions fall into exactly two buckets, and knowing the difference is what separates a candidate who scopes like an engineer from one who just lists features. Functional requirements are what the system does. Non-functional requirements are how well it has to do it. Freshers nail the first bucket and forget the second - which is a problem, because the second bucket is the one that actually decides your architecture.
This is the third post in the System Design Guide series. Earlier we covered how to scope a problem and how to recover when your mind blanks; here we go deep on the two kinds of requirements, why non-functional ones drive the design, and the concrete questions to ask for the classic interview problems.
The one-line difference
| Functional | Non-functional | |
|---|---|---|
| Question it answers | "What can a user do?" | "How well must it do it?" |
| Form | Features, behaviors, verbs | Qualities, constraints, numbers |
| Examples | Post a tweet, view a timeline, follow a user | 10M DAU, sub-200ms reads, 99.9% uptime, eventual consistency |
| Interview signal | Table stakes - you're expected to get these | Where senior signal lives - these force trade-offs |
| Drives | The API surface and data model | The whole architecture: caching, sharding, replication, DB choice |
A useful test: if a requirement can be written as a sentence with the user as the subject and a verb ("a user can upload a photo"), it's functional. If it's a number or a quality with no user verb ("photos load in under 200ms," "the system stays up during a node failure"), it's non-functional.
Functional requirements: pin the feature set
Functional requirements are the handful of things the system must let someone do. You are not building all of Twitter - you and the interviewer agree on the two or three core features that matter for this session, and everything else is explicitly out of scope.
The generic questions that surface them, on any problem:
- What are the core features we must support?
- Who are the actors (end user, admin, another service)?
- Web, mobile, or both?
- Is [feature X] in scope - search, notifications, media, deletion, editing?
The output of this bucket is a short feature list you write on the board and treat as a contract, plus the API endpoints those features imply. "A user can publish a post and see friends' posts" becomes POST /v1/me/feed and GET /v1/me/feed. That's it. Keep it small on purpose - an agreed feature that isn't on the list is one you get to skip without penalty.
Non-functional requirements: the ones that shape the design
This is the bucket that turns a toy into a system, because each non-functional requirement forces a specific architectural decision. Here are the axes, what to ask for each, and - the important part - what each one changes.
Scale and throughput
Ask: How many daily active users? Reads and writes per second? What growth in 3, 6, 12 months? Changes: Whether a single database is fine or you need sharding, caching, load balancers, and a CDN. Everything downstream is sized off these numbers.
Read vs write ratio
Ask: Is this read-heavy (a timeline, a product page) or write-heavy (a logging pipeline, analytics ingestion)? Changes: A heavily read-skewed system wants caching, read replicas, and precomputed views - the classic case for splitting the read path from the write path with a pattern like CQRS. A write-heavy one wants queues, batching, and write-optimized storage.
Latency
Ask: Does a request need to feel instant (sub-100ms) or is a few seconds acceptable? Changes: Tight latency pulls in in-memory caches, edge/CDN delivery, geographic distribution, and precomputing results ahead of the request instead of computing them on read.
Availability
Ask: What uptime do we need? Is brief downtime acceptable, or is this critical-path? Changes: High availability (the "nines") means replication, automatic failover, and removing every single point of failure - often multi-region. 99.9% vs 99.99% is a real jump in cost and complexity, so pin the target.
Consistency
Ask: Must every read return the latest write (strong consistency), or is slightly stale data acceptable for a while (eventual consistency)? Changes: This is the CAP trade-off. When a network partition happens, a distributed system must choose between consistency and availability - you cannot have both. A bank balance needs strong consistency (a CP system that would rather error than show stale data); a social feed is fine with eventual consistency (an AP system that stays up and syncs shortly after). This choice drives your database family: a relational/strongly-consistent store vs an AP store like Cassandra or Dynamo-style systems.
Durability
Ask: If a server dies, can we lose any data? How much, and for how long must data live? Changes: Zero data loss means replication, write-ahead logs, quorum writes, and backups. Retention ("store chat history forever," "keep crawled pages for 5 years") sizes your storage and pushes cold data to cheaper tiers.
Data size and media
Ask: How big is a record? Do we store images or video? How long is it retained? Changes: Large media should never flow through your application servers - clients upload straight to object storage using presigned URLs, and reads come off a CDN. Text-only systems skip all of that.
Security and cost
Ask: Auth model? Any encryption requirement (for example, end-to-end for a chat app)? Rate limiting? Any hard budget? Changes: These add auth services, encryption, and throttling - and cost is the quiet reminder not to over-engineer. A design for a startup looks nothing like one for 500M users; build for the scale you were actually given, not the most impressive one.
Questions to ask, by problem
The axes above are generic. In the room you ask the specific version for the problem in front of you. Here are the real clarification questions for the classic interview prompts, split into the two buckets.
Design Twitter / a news feed
| Functional | Non-functional |
|---|---|
| Publish a post, and see friends' posts on a feed? | How many daily active users? (e.g. 10M DAU) |
| Web, mobile, or both? | How many friends/follows can a user have? (e.g. 5000) |
| Reverse-chronological, or ranked by score? | Read-heavy or write-heavy? (feeds are read-heavy) |
| Can a post contain images and video, or text only? | Is eventual consistency on the feed acceptable? |
| Are likes, comments, retweets in scope? | Acceptable feed load latency? |
Design a chat app
| Functional | Non-functional |
|---|---|
| One-on-one, group chat, or both? | What scale? (e.g. 50M DAU) |
| Online/presence indicator in scope? | Max group size? (e.g. 100 members) |
| Text only, or attachments too? | Delivery latency target (chat must feel real-time)? |
| Multi-device support for one account? | Message size limit? (e.g. under 100k characters) |
| Push notifications when offline? | End-to-end encryption required? How long to retain history? |
Design a URL shortener
| Functional | Non-functional |
|---|---|
| Shorten a long URL, and redirect a short one back? | Traffic volume? (e.g. 100M new URLs/day) |
| Can short URLs be custom/aliased? | Read-to-write ratio? (redirects dominate, often ~10:1) |
| Can they be deleted or updated? | How short must the short URL be, and which characters? |
| Do we track click analytics? | Retention / how many years of records to support? |
| Do links expire? | Availability - redirects are critical path, so very high |
Design a rate limiter
| Functional | Non-functional |
|---|---|
| Client-side or server-side API rate limiter? | Must handle a large request volume with low latency |
| Throttle by IP, user ID, or configurable rules? | Must work in a distributed environment (shared across servers) |
| Do we inform throttled users (which response/headers)? | Minimal memory footprint |
| Separate service or embedded in app code? | Fault tolerant - if it fails, it must not take the app down |
Design a key-value store
| Functional | Non-functional |
|---|---|
Simple get(key) / put(key, value) API? |
Value size limit? (e.g. under 10KB) |
| Support for large datasets ("big data")? | High availability - respond quickly even during failures |
| Automatic add/removal of nodes? | Tunable consistency (pick your CAP trade-off) |
| Low latency, and horizontal scalability |
Notice the pattern: the functional column is short and problem-obvious; the non-functional column is where the interesting, design-defining numbers live. That asymmetry is exactly why skipping the second bucket gets you graded as junior.
Not every question is worth asking
Clarifying questions are not free. Some narrow the problem and cost you nothing; others quietly sign you up for a whole extra subsystem and burn the clock you needed for the core design. The skill is to ask the narrowing ones and to cut the expanding ones with a stated assumption instead of an open question. There's a simple asymmetry worth internalizing: a question that adds a constraint is safe to ask; a question whose "yes" adds a feature is usually one you should answer yourself.
Rank every clarifying question into three tiers.
Tier 1 - always ask (they narrow scope, cost nothing). Skipping these means designing blind, and none of them expand the problem:
- Core features (the 2 to 3 must-haves)
- Scale: DAU / QPS / growth
- Read vs write ratio
- Latency target
- Consistency: strong or eventual (for anything distributed)
Tier 2 - pick exactly one hard thing. Every good problem has one "interesting" complexity that is the whole point of the interview, and you want it because it is where you show depth. But take one, not three:
- Media in a news feed (object storage + CDN + presigned uploads)
- Celebrity or group fanout in a feed or chat
- Hash design and collisions in a URL shortener
- CAP tuning in a key-value store
Reach for the one the interviewer leans toward and design it deeply.
Tier 3 - avoidable: cut by default. These are the questions whose "yes" drags in an extra subsystem you will then feel obligated to design. Don't raise them as open questions - state an assumption that cuts them, and only pursue if the interviewer bites: "I'll assume no X for now to keep scope tight, and we can add it if there's time."
Here is the cut list, roughly ranked from the most complexity each one pulls in down to the least:
| Question (by problem) | What its "yes" pulls in | Complexity | Default to |
|---|---|---|---|
| Feed: reverse-chronological or ranked? | A full ML scoring/ranking pipeline | Very high | Reverse-chronological |
| URL / feed: click or view analytics? | A separate analytics/event pipeline | High | Out of scope |
| Chat: end-to-end encryption? | Key exchange, per-device keys | High | No (the book itself defers this) |
| Chat: multi-device support? | Cross-device sync, per-device delivery queues | High | Single device |
| Feed: likes / comments / retweets? | Extra write paths, counters, notifications | Medium-high | Out of scope unless asked |
| Push notifications? | Notification service, delivery, presence | Medium-high | Out of scope unless it's the topic |
| Posts/messages editable or deletable? | Edit history, cache invalidation, tombstones | Medium | Immutable |
| URL: custom alias? | Collision handling on user-chosen keys | Medium | System-generated only |
| URL: link expiry / TTL? | Background cleanup, expiry checks | Low-medium | No expiry |
Two things stand out. First, group chat is the interesting exception - it is a real subsystem (fanout to N members, membership management), so it belongs in Tier 2 if you want it as your hard problem, and in Tier 3 (assume one-on-one) if you don't. Second, notice the highest-complexity items - ranked feeds, analytics, end-to-end encryption - are almost always the most avoidable: they each add an entire subsystem while rarely being what the interviewer actually wants to see. Cut them out loud, write the assumption on the board, and spend the saved minutes going deep on your one Tier 2 problem.
From answers to architecture
Requirements are not a formality - each answer is a lever. Once they're on the board, they map straight to numbers and components:
- "100M URLs/day, 10:1 read:write" -> ~1,160 writes/sec, ~11,600 reads/sec -> a cache in front of the redirect path.
- "10M DAU, up to 5000 friends, read-heavy" -> precompute feeds (fanout on write) so reads are cheap.
- "tunable consistency, high availability" -> an AP data store, not a single relational primary.
- "stores images and video" -> object storage plus CDN, uploads via presigned URLs.
You do the back-of-the-envelope math on the non-functional numbers, and the architecture starts choosing itself.
A checklist you can run on any problem
When a new prompt lands and you want a reusable script, ask these in order:
Functional (what):
- Core features - what are the 2 to 3 must-haves?
- Actors and platforms - who uses it, web/mobile/both?
- What's explicitly out of scope?
Non-functional (how well):
- Scale - DAU, QPS, growth?
- Read vs write ratio?
- Latency target?
- Availability / uptime need?
- Consistency - strong or eventual?
- Durability and data size/retention?
- Security, and any cost/simplicity constraint?
You will not ask all twelve on every problem - pick the ones that move this design. But running the checklist means you never stare at a blank board wondering what to ask next.
You now have both buckets
Functional requirements give you the feature list and the API; non-functional requirements give you the numbers and qualities that decide caching, sharding, replication, consistency, and your database itself. Sort every clarification question into one of the two, get the non-functional numbers explicitly (never assume them), and your design will be anchored to real constraints instead of guesses.
Earlier in this series we scoped the problem and handled the opening blank; with the requirements now pinned, the next post takes them and turns them into the high-level design - the boxes, the APIs, and the data flow the interviewer wants to see next.