Features say what. System qualities shape how.#
For a chat product, “send a message,” “receive a message,” and “load history” are functional requirements. “Deliver active-user messages quickly,” “remain available,” “do not lose acknowledged messages,” and “preserve a sensible order” are non-functional requirements.
The feature list tells you what paths must exist. The qualities often drive the harder architecture decisions: persistent delivery, geographic placement, acknowledgement rules, replication, and ordering.
Functional requirements: negotiate the essential product#
Functional requirements describe observable behavior. Keep the interview scope small enough to design well. For a video service, uploading and watching may be primary; comments, likes, subscriptions, search, and recommendations are candidates for explicit exclusion or a later extension.
Non-functional requirements: translate goals into design pressure#
| Property | Question to clarify | Possible design consequence |
|---|---|---|
| Latency | Which operation is user-visible, and how fast is “fast enough”? | Shorter synchronous path, closer serving location, faster access path |
| Throughput | What peak read/write rate must the system sustain? | Parallel workers, horizontal scale, partitioning, buffering |
| Availability | Which operations must keep working during a failure? | Redundant instances, failover, graceful degradation |
| Reliability | What incorrect or duplicate outcomes are unacceptable? | Idempotency, validation, auditable state changes |
| Durability | After acknowledging a write, what loss is acceptable? | Persistent storage, acknowledgement policy, backups |
| Consistency | How stale may each read be? | Read routing, coordination, conflict handling |
| Scalability | How may workload and data grow? | Stateless services, partitionable data, capacity boundaries |
| Fault tolerance | Which failures should the product mask or degrade through? | Isolation, retry budgets, redundancy, fallback behavior |
Numbers are example requirements, not universal targets. If active-user message delivery should normally stay under roughly 200 ms, the design may favor persistent connections, geographically close servers, fast routing, and fewer slow synchronous dependencies. A different product could accept a different boundary.
Requirements change the architecture#
Payment system
Functional: create a payment, retrieve its status, and issue a refund. Non-functional: prevent duplicate charges, preserve acknowledged state, retain an audit trail, and favor correctness around money movement.
News feed
Functional: publish a post and retrieve a feed. Non-functional: low read latency and high availability may dominate, while some products can accept delayed feed propagation. Product expectations can change that consistency choice.
File storage
Functional: upload, download, and delete. Non-functional: durable acknowledged writes, large-file support, resumable transfer, and high availability. Retention and sharing semantics still need clarification.
Exercise: scope WhatsApp#
Write three essential functional requirements and four non-functional requirements. Add at least one explicit exclusion.
Reveal one reasonable answer
Functional: send one-to-one messages, receive messages, and load recent history. Exclude group chat, voice/video, stories, and payments for the first design.
Non-functional: low delivery latency for online users, durable acknowledged messages, sensible per-conversation ordering, high availability, and support for intermittent connections. Exact targets must still be negotiated.
Turn each requirement into a question#
Do not merely list “availability” or “consistency.” Connect it to an operation: can users read history during a regional failure? Can a newly sent message appear briefly out of order? When is a send acknowledged? Architecture becomes defensible when each choice traces back to an agreed behavior or quality.
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Design architecture based on business requirementsMicrosoft Azure Well-Architected Framework
- SimplifyMicrosoft Azure Well-Architected Framework