Non-Functional Requirements & Infrastructure Constraints

The Landscape of Non-Functional Requirements

Before we dive into specific examples, it's helpful to appreciate the breadth of non-functional requirements. As an experienced engineer, you've encountered many of these, perhaps under different names like "quality attributes," "-ilities," or "cross-cutting concerns." They define how a system should operate, as opposed to what it should do.

The following mind map provides an excellent visual overview of the major categories of NFRs. It's a useful reference for the variety of constraints you must consider during system design.

NFRs are the bridge between high-level business goals and concrete technical decisions. A business need like "we need to be able to serve customers globally" translates into technical NFRs for latency and availability, which in turn dictate infrastructure choices about cloud regions and Content Delivery Networks (CDNs).

To formalize this, let's look at a clear definition and a structured way to capture these requirements.

Core NFRs as Infrastructure Constraints

Now, let's dissect some of the most critical NFRs and see how they directly constrain our infrastructure decisions. We will focus on the examples from the learning outcome, but also include others that are deeply interconnected.

1. Availability and Reliability

Availability is the measure of a system's uptime, famously expressed in "nines" (e.g., 99.99% "four nines" availability). Reliability is a broader concept encompassing not just uptime but also the system's ability to function correctly without failure over time.

These NFRs are often the most visible to end-users and have direct revenue implications. They are also a classic example of how a business requirement translates into non-negotiable infrastructure constraints.

To understand the practical aspects of defining and negotiating these requirements, the following video offers a great walkthrough.

As the video illustrates, an NFR for high availability directly constrains your infrastructure in several ways:

• Redundancy: You are forced to eliminate single points of failure. This means deploying applications across multiple availability zones (AZs) or even regions.
• Failover: You must have automated mechanisms to redirect traffic away from failed components. This necessitates the use of load balancers, health checks, and DNS-based failover strategies.
• Data Durability: You need to use storage and database services that replicate data across multiple locations to survive a zone or regional failure (e.g., using a managed database service like Amazon RDS in a Multi-AZ configuration).
• Disaster Recovery (DR): You must have a plan and the corresponding infrastructure for recovering from a catastrophic event. This might involve choices like active-passive or active-active multi-region setups.

2. Performance: Latency and Throughput

Performance is often discussed as a single concept, but it's critical to decompose it into two distinct metrics: latency and throughput. They are often in tension, and understanding the difference is key to making correct infrastructure choices.

• Latency: The time it takes to complete a single operation. Think of it as "how fast."
• Throughput: The number of operations that can be processed in a given time period. Think of it as "how much."

A deep dive into these two concepts is essential.

How do latency and throughput constrain infrastructure?

• Latency Constraints:

  • Proximity: To minimize network latency for users, you are constrained to host your servers in cloud regions geographically close to them.
  • Caching: You are often forced to introduce caching layers (e.g., Redis, Memcached) to serve frequent requests from fast in-memory stores instead of slower disks.
  • Content Delivery: For static assets, low latency requirements mandate the use of a Content Delivery Network (CDN) to cache content at edge locations worldwide.

• Throughput Constraints:

  • Horizontal Scalability: To handle high TPS, your infrastructure must be able to scale horizontally. This forces you to use load balancers and auto-scaling groups for your compute layer (VMs or containers) or to adopt a serverless architecture that scales automatically.
  • Component Capacity: Each component in the request path must be able to handle the target throughput. This constrains your choice of database (connection limits), message queues (consumer capacity), and any third-party APIs (rate limits).

3. Security and Compliance

For many systems, security and compliance are the most rigid constraints of all. Compliance, in particular, involves adhering to legal and industry standards (e.g., GDPR, HIPAA, PCI-DSS) that are often non-negotiable.

These NFRs can drastically narrow your available infrastructure options:

• Data Residency: Regulations like GDPR may legally require you to store and process user data within specific geographic boundaries (e.g., the EU), constraining your choice of cloud regions.
• Certified Services: Standards like HIPAA (for healthcare data) or FedRAMP (for US government data) require you to use cloud services that have been officially certified as compliant. This limits you to a specific subset of a provider's offerings (e.g., "HIPAA-eligible services").
• Security Controls: Requirements for encryption (in transit and at rest), network isolation (VPCs, subnets, security groups), and access control (IAM) are fundamental infrastructure design decisions, not features to be added later.

4. Observability

Observability is the ability to infer a system’s internal state from its external outputs—logs, metrics, and traces. It's a modern evolution of "monitoring." A system is not observable by accident; it must be designed for it.

This NFR constrains your infrastructure to include components that facilitate deep introspection:

• Metrics: Your compute, database, and networking components must expose detailed performance metrics. This might influence you to choose a service with more granular monitoring capabilities.
• Logging: You need a centralized logging solution (e.g., ELK Stack, Splunk, Datadog) to aggregate logs from all your distributed components. Your infrastructure must be configured to ship logs to this central location.
• Tracing: To understand latency in a distributed system, you need to implement distributed tracing. This constrains you to use application libraries, service meshes (like Istio), or cloud provider services (like AWS X-Ray) that support it.

The Interplay of NFRs: A World of Trade-offs

Crucially, these NFRs do not exist in isolation. They often conflict, forcing you to make the trade-offs we discussed in the last lesson. For example:

• Increasing security (e.g., by adding more encryption and validation layers) might negatively impact performance (increase latency).
• Designing for very high availability (e.g., with multi-region replication) will significantly increase cost.
• Optimizing for performance with aggressive caching can sometimes complicate data integrity.

This matrix illustrates some of the common relationships between quality attributes. A "+" indicates a positive correlation (improving one helps the other), while a "-" indicates a negative correlation or trade-off.

Recognizing these conflicts is central to your role. Your job is not to build a system that is infinitely available, infinitely fast, and infinitely cheap. Your job is to use a structured process to choose the architectural and infrastructure options that best satisfy a prioritized set of NFRs, as dictated by business goals.

Conclusion

In this lesson, we established the critical link between non-functional requirements and concrete infrastructure choices. We have moved from the how of trade-off analysis to the what—the criteria you will use to evaluate your options.

Key Takeaways:

• NFRs are not a wishlist; they are hard constraints that define the operational boundaries of your system and are derived from business needs.
• Availability drives the need for redundancy and failover, constraining you to multi-AZ/multi-region architectures and resilient services.
• Performance (Latency & Throughput) dictates infrastructure topology, including geographic placement, caching, CDNs, and horizontal scaling capabilities.
• Compliance & Security can be absolute constraints, severely limiting your choice of cloud provider, region, and services to those with specific certifications.
• Observability is a design-time concern that requires an infrastructure capable of producing and aggregating detailed logs, metrics, and traces.
• NFRs are often in conflict, requiring the deliberate, structured trade-off analysis that we covered in the previous lesson.

Preview of the Next Lesson:

Now that you can identify how NFRs constrain your options, we will apply this thinking to one of the most fundamental infrastructure decisions an architect faces. In the next lesson, we will assess the trade-offs of managed services versus self-hosted solutions in terms of control, cost, and operational burden.