Functional vs Non-Functional Requirements

Every system design exercise, whether in an interview or in real product development, starts with gathering requirements, and those requirements fall into two categories that pull architecture in different directions. Functional requirements describe what the system must do — the concrete features and behaviors a user or client can observe, such as 'users can post a tweet' or 'the system returns search results for a query.' Non-functional requirements (NFRs) describe how well the system must do it — qualities like latency, availability, consistency, durability, and cost that are invisible in a feature list but dominate the actual architecture. Two systems with identical functional requirements (e.g., a chat app) can have wildly different architectures depending on their NFRs (e.g., must messages be delivered in order, must they survive a data-center failure, what's the acceptable p99 latency).

Functional requirements should be scoped explicitly and narrowly, especially in an interview: rather than designing 'all of Twitter,' a candidate should list the 3-5 core user-facing actions actually in scope — post a tweet, follow a user, view a home timeline — and explicitly state what is out of scope (e.g., direct messages, ads, analytics). This scoping discipline prevents an interview or a real design document from sprawling into an unbounded surface area, and it gives every subsequent architectural decision a clear justification tied back to a specific feature.

NFRs are typically expressed as measurable targets: availability (e.g., 99.99% uptime, translating to about 52 minutes of downtime per year), latency (e.g., p99 read latency under 200ms), scalability (e.g., support 10 million daily active users, 5,000 writes per second at peak), consistency (e.g., eventual consistency is acceptable for a like counter, but strong consistency is required for a bank balance), and durability (e.g., no data loss once a write is acknowledged). Because NFRs are the primary driver of architecture — a strong-consistency requirement rules out certain caching strategies, and a low-latency global requirement forces multi-region deployment — a design that skips NFR gathering usually produces an architecture that is either wildly over-provisioned or quietly broken under real load.