🔷 Functional vs Non-Functional Requirements (Interview Version)

🟢 Functional Requirements = "WHAT system does"

👉 Core features / user actions

Examples

• Login → user can sign in
• YouTube → upload, watch, like videos
• Uber → book ride, track driver

🔥 Tip

If you remove all UI → whatever actions remain = functional requirements

💬 Say (memorize this):

"Let me start by defining the functional requirements — these are the core actions users can perform in the system. For this design, the key features are: [list 5–7 features]. I'm intentionally keeping this focused — I want to avoid scope creep and make sure we cover the most critical paths deeply."

🔵 2. Non-Functional Requirements = "HOW system behaves"

👉 System quality, scale, constraints

Key Types (must remember)

• Scalability → handle growth (1K → 1M users)
• Latency/Performance → fast response (e.g., <200ms)
• Availability → uptime (99.9%, 99.99%)
• Consistency → same data everywhere
• Durability → data never lost
• Security → auth, encryption
• Reliability → works correctly over time

Examples

• WhatsApp → messages delivered in <100ms (performance)
• Netflix → works even during peak traffic (scalability)
• Banking → no data loss (durability + consistency)

💬 Say (memorize this):

"Now let me define the non-functional requirements — these are what actually drive the architecture decisions.

The system needs to support roughly [X] million daily active users. Latency should be under 200ms at p99 for read operations. Availability should be 99.99% — that's less than an hour of downtime per year. The workload is read-heavy, with roughly a 10-to-1 read/write ratio. Feed updates can be eventually consistent, but writes — like post creation — must be strongly consistent. The system must be durable, fault-tolerant, and cost-efficient."

"The reason non-functional requirements matter so much is that they directly force specific architectural decisions. For example, if we need low latency at massive scale, we can't just query a single relational database — we need caching, sharding, and CDNs. So I always define these early, because they shape every decision I make going forward."

---

⚖️ 3. Trade-offs (VERY IMPORTANT)

Interviewers love this.

Example:

• Strong consistency vs availability → Banking vs Social Media

• Read-heavy vs Write-heavy → YouTube (reads >> writes)

💬 Say (memorize this):

"Every non-functional requirement involves trade-offs. For example, if we prioritize strong consistency, we sacrifice some availability — this is the CAP theorem in practice. In a social feed, we can accept eventual consistency because showing a post 1 second late is fine. But in a banking system, we must have strong consistency — a balance must never be wrong. So I'm choosing to optimize for [X], which means we accept the trade-off of [Y]."