Theory
Non-Functional Requirements (NFRs)
📋 Overview
In system design, Functional Requirements define what the system does (e.g., "A user can post a tweet"). Non-Functional Requirements (NFRs) define how the system performs under pressure. They are the constraints and quality attributes that dictate the architectural choices—such as picking a NoSQL DB over SQL or choosing an Active-Active multi-region setup.
🏗️ Core Principles & Characteristics
- The "Big Five":
- Scalability: Ability to handle growth (Horizontal vs. Vertical).
- Availability: The percentage of "uptime" (The "Nine's"—e.g., 99.99%).
- Reliability: The probability that the system performs its function without failure.
- Performance: Latency (response time) and Throughput (requests per second).
- Consistency: The "C" in CAP—ensuring all nodes see the same data at the same time.
- The "Qualities" (The "-ilities"): Security, Durability, Maintainability, Portability, and Observability.
⚖️ Trade-offs: Pros & Cons
- Consistency vs. Availability (CAP Theorem): In a network partition, you must choose between returning a potentially stale answer (Availability) or returning an error until the data is synced (Consistency).
- Latency vs. Throughput: You can batch requests to increase throughput, but this increases the latency of individual requests.
- Cost vs. Redundancy: High availability requires doubling or tripling your infrastructure, which increases costs significantly.
🌍 Real-World Implementation
- E-commerce: Prioritizes Availability over Consistency. You'd rather let a user add an item to their cart (even if inventory is slightly off) than show them a 500 error page.
- Banking: Prioritizes Consistency and Durability. A transaction must be 100% correct and never lost, even if the system is slightly slower.
- Ad-Tech: Prioritizes Latency. An ad must be served in <20ms, or the bidding window is lost. "Good enough" data is acceptable.
💡 Interview "Gotchas" & Tips
- Quantify your NFRs: Don't just say "The system should be fast." Say "The P99 latency should be under 200ms for 100k Concurrent Users."
- The SLA/SLO/SLI Framework:
- SLI (Indicator): What we measure (Latency).
- SLO (Objective): The target we set (Latency < 200ms).
- SLA (Agreement): The legal contract (We pay you if Latency > 200ms).
- Back-of-the-Envelope Estimates: Use your NFRs (e.g., 10M DAU) to estimate QPS and storage needs. This proves your design is grounded in reality.
📐 Suggested Architecture Primitives
- Load Balancers: To achieve Scalability and Availability.
- Health Checks: To automate Self-Healing and Reliability.
- Distributed Tracing: To monitor the Performance of microservices.
- Write-Ahead Logs (WAL): To guarantee Durability during crashes.
Canvas