System Design · Architecture under constraints
What is the difference between functional and non-functional requirements?
Short answer
Functional requirements describe what the system does, such as posting a message or processing a payment. Non-functional requirements describe how well it must do it: latency, availability, durability, consistency and cost.
Functional requirements become features, APIs and data flows. Non-functional requirements become architectural constraints. A system that can post a message satisfies a functional requirement; a system that delivers that message with p99 latency under 200 milliseconds and no loss satisfies non-functional ones.
Functional examples
- A user can shorten a URL and receive a redirect
- A seller can list an item and a buyer can purchase it
- A user can follow another user and see their posts
- An operator can refund a payment
Non-functional examples
- p99 read latency under 100 milliseconds at peak
- 99.99 percent monthly availability, with a defined error budget
- No acknowledged write is lost after a single node failure
- Reads are strongly consistent after a write returns
- Storage cost stays under a stated amount per active user
- The system remains operable during a rolling deploy
The useful move is to make non-functional requirements falsifiable. Replace fast, reliable and scalable with a percentile, a window and a failure model. Ask what happens at peak, during a region failure, and when data is replicated asynchronously. Those questions expose whether a design is actually meeting the requirement.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How do you make an availability requirement testable?
- 2Which non-functional requirement most affects the data layer?
- 3How would you prioritize latency against cost?
- 4What happens when two non-functional requirements conflict?
Say it in the interview
Functional requirements tell me what the system must do, while non-functional requirements set the quality bar: latency percentiles, availability, durability, consistency and cost. I turn each quality word into a measurable target and a failure model, because otherwise it cannot guide design. Then I call out the conflicts, such as consistency versus latency, and state which one the product actually needs.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live System Design mock interview and get scored feedback on depth, clarity and confidence.