1Which of the following is a non-functional requirement?
Vetora🔍Interview Toolkit
Clarifying Requirements
Learn how to spend the first 5 minutes of a system design interview gathering functional requirements, non-functional requirements, scale estimates, and constraints -- the foundation that determines every subsequent design decision.
Overview
The first five minutes of a system design interview are the most leveraged minutes of the entire conversation. Every design decision you make -- the database technology, the caching strategy, the communication protocol, the consistency model -- flows from the requirements you establish at the start. A URL shortener with a 100:1 read-to-write ratio demands a completely different architecture than one with a 1:1 ratio. A chat system for 1:1 conversations has different fan-out characteristics than one supporting 10,000-member groups. A payment system that must comply with PCI-DSS has constraints that reshape the entire data flow. Candidates who skip this step or rush through it almost always build the wrong system.
Functional requirements define what the system does. Frame them as user stories or API endpoints: 'A user can create a short URL from a long URL,' 'A user can be redirected when visiting a short URL,' 'An admin can view analytics for a short URL.' Be explicit about what is in scope and what is not. If the interviewer says 'Design a URL shortener,' ask whether custom aliases are needed, whether analytics are required, whether URLs expire, and whether there is an API for programmatic access. The goal is to turn an ambiguous prompt into a concrete list of 4-6 capabilities.
Non-functional requirements define how the system performs. The key dimensions are latency (p50 and p99 response times), throughput (requests per second the system must handle), availability (what SLA -- 99.9% means 8.7 hours of downtime per year, 99.99% means 52 minutes), consistency (strong vs eventual -- does a newly created short URL need to be immediately resolvable?), and data retention (how long is data kept, are there deletion requirements?). These dimensions drive technology choices: strong consistency points toward relational databases; high throughput with eventual consistency points toward NoSQL; sub-10ms latency demands caching.
Scale estimation translates business metrics into engineering numbers. Start with DAU (daily active users), derive QPS (if 100M DAU and each user makes 5 requests/day, that is 500M requests/day or roughly 5,800 QPS average, with a peak of 2-3x), estimate storage (if each record is 500 bytes and you create 10M records/day, that is 5GB/day or 1.8TB/year), and calculate bandwidth (5,800 QPS times 500 bytes is about 3MB/s). The 'newspaper test' is a useful heuristic: if your design appeared on the front page of a newspaper, would the requirements be specific enough that any engineer could evaluate whether the design meets them? If not, keep clarifying.
Key Points
- 1Functional requirements define what the system does. Express them as user stories or API endpoints and explicitly state what is out of scope. Four to six well-defined capabilities are enough to anchor the design.
- 2Non-functional requirements define how the system performs. Always clarify latency targets (p99), throughput (QPS), availability SLA, consistency model, and data retention. These drive every technology and architecture choice.
- 3Scale estimation converts business metrics to engineering numbers. The chain is DAU to QPS to storage to bandwidth. Memorize the conversion factors: 1 day is approximately 100K seconds, so dividing daily volume by 100K gives approximate average QPS.
- 4Constraints are requirements you would not guess without asking. Budget limits, regulatory compliance (GDPR, PCI-DSS, HIPAA), existing infrastructure that must be reused, and team expertise all shape the design in ways that pure technical requirements do not.
- 5The 'newspaper test' ensures your requirements are specific enough: if published on a front page, could any engineer evaluate whether a proposed design satisfies them? Vague requirements like 'low latency' fail the test; 'p99 read latency under 50ms' passes.
- 6Write requirements down on the whiteboard. This creates a shared contract between you and the interviewer, prevents scope creep, and gives you a reference to point back to when justifying design decisions later in the interview.
Simple Example
The Restaurant Order Analogy
Imagine a waiter who brings food to the table without asking what you want. They might bring a steak to a vegetarian or a mild dish to someone who wanted extra spice. Clarifying requirements is the equivalent of taking a careful order: 'How would you like your steak cooked? Any allergies? Do you want the soup as a starter or with the main course?' A 30-second conversation at the start prevents a 10-minute mistake. In system design interviews, five minutes of requirements gathering prevents 40 minutes of building the wrong system.
Real-World Examples
URL Shortener (Bitly-style)
The read-to-write ratio changes everything in a URL shortener design. If the ratio is 100:1 (which is typical -- URLs are created once and clicked many times), the system is read-heavy and benefits from aggressive caching and read replicas. If it were 1:1, caching would have lower hit rates and the write path would need more attention. Without clarifying this ratio, a candidate might over-invest in write optimization or miss the opportunity to demonstrate caching knowledge.
Chat System (Slack/WhatsApp-style)
Asking whether the chat system supports only 1:1 messaging or also group chats with up to 100,000 members changes the architecture fundamentally. 1:1 messages are simple point-to-point delivery. Large group messages require fan-out strategies -- write-time fan-out (copy the message to each recipient's inbox at send time) versus read-time fan-out (store once, query at read time). The group size constraint determines which approach is feasible.
Payment System (Stripe-style)
A payment system interview surfaces requirements that candidates would never guess without asking. PCI-DSS compliance mandates that cardholder data must be encrypted at rest and in transit, stored in isolated network segments, and subject to audit logging. GDPR may require data residency in specific regions. Idempotency is non-negotiable for financial transactions. These compliance-driven requirements add components (tokenization service, audit log, regional data stores) that reshape the entire architecture.
Trade-Offs
| Aspect | Description |
|---|---|
| Time Spent vs Information Gained | Spending too long on requirements eats into design time. Spending too little leads to wrong assumptions. The sweet spot is 5 minutes: enough to establish scope, scale, and key constraints, but not so long that you have less than 35 minutes for the actual design. |
| Specificity vs Flexibility | Pinning down very specific numbers (exactly 50ms p99 latency) gives you clear targets to design against. But being too specific can box you in if the interviewer wanted a more exploratory discussion. State your assumptions explicitly and invite the interviewer to adjust them. |
| Asking vs Assuming | Some interviewers want you to ask questions; others want you to state reasonable assumptions and move on. Read the room: if the interviewer gives detailed answers, keep asking. If they say 'whatever you think is reasonable,' state your assumptions clearly and proceed. |
| Breadth vs Depth of Requirements | You could clarify dozens of edge cases or focus on the 4-6 most impactful requirements. In a time-constrained interview, prioritize the requirements that actually change the architecture: scale, consistency model, latency targets, and compliance constraints. Secondary requirements can be noted and addressed later. |
Case Study
How Clarifying Requirements Saved a Rate Limiter Design
Scenario
A candidate was asked to design a rate limiter. They immediately began designing a token bucket algorithm with Redis counters. Midway through, the interviewer asked, 'What about distributed rate limiting across multiple data centers?' The candidate's single-Redis design could not handle cross-datacenter coordination, and they had to restart with 25 minutes left. The root cause: they never asked whether the rate limiter was for a single service instance, a cluster, or a globally distributed system.
Solution
In a subsequent mock interview, the same candidate opened with targeted questions: Is this a local rate limiter (per-instance) or global (across all instances)? Is it single-datacenter or multi-datacenter? What are the rate limit rules (per-user, per-IP, per-API-key)? What happens when the limit is exceeded (429 response, queue, degrade)? Is exact accuracy required or is approximate acceptable? The answers -- global, multi-datacenter, per-user, approximate -- led to a design using local sliding-window counters with periodic synchronization to a central store, accepting a small over-limit tolerance for the benefit of low latency and datacenter independence.
Outcome
The requirements-first approach produced a design that was architecturally sound from the start. The candidate spent 18 minutes on the deep dive discussing the synchronization protocol, conflict resolution for counter updates, and the trade-off between accuracy and latency. The interviewer rated it a strong hire, noting that the requirements phase demonstrated the candidate understood the problem space before proposing solutions.
Common Mistakes
- ⚠Asking zero questions and immediately starting to draw. This signals to the interviewer that you build before you think, which is the opposite of what senior engineers do. Even if the problem seems obvious, confirm your assumptions.
- ⚠Asking only functional requirements and ignoring scale. A system for 100 users and a system for 100 million users share almost no architectural decisions. Always establish DAU, QPS, and storage estimates before designing.
- ⚠Treating requirements gathering as a checklist rather than a conversation. Rapid-fire questions without listening to the answers miss the nuance the interviewer is providing. Each answer should inform your next question.
- ⚠Not writing requirements on the whiteboard. Verbal agreements are forgotten under interview pressure. Write the key requirements in a corner of the board and reference them when justifying design decisions -- it shows rigor and keeps you on track.
Related Concepts
See Clarifying Requirements in action
Explore system design templates that use clarifying requirements and run traffic simulations to see how these concepts perform under real load.
Browse TemplatesExplore how requirements change simulation outcomes
Metrics to watch
read_write_ratiopeak_rpsstorage_tbp99_latency_ms
Test Your Understanding
2Why does the read-to-write ratio matter when designing a URL shortener?
3What is the 'newspaper test' for requirements?