Understanding Quality Attributes and Their Metrics

What Are Quality Attributes?

Quality attributes describe the characteristics of a system that determine its quality of service. They are the "-ilities" of a system: scalability, reliability, maintainability, and so on. They are not features you can point to on a screen, but they are just as critical to the system's success. A system that has every feature but is slow, unreliable, and insecure is a failure.

Good architecture begins by identifying which of these qualities are most important for a given business context. You can't maximize all of them simultaneously.

To start, let's get a broad overview of the most common quality attributes.

As the article explains, these attributes are goals that drive architectural decisions. For instance:

• To achieve Availability, an architect might choose design pillars like redundancy and fault tolerance.
• To achieve Scalability, they might enforce statelessness and partitioning.

For the rest of this lesson, we will focus on two of the most fundamental attributes—Performance and Scalability—and their specific metrics.

Deep Dive: Performance

Performance is often the most visible quality attribute to end-users. It generally answers two questions: "How fast is it?" and "How much can it handle?". These two questions correspond to two distinct, though related, metrics: Latency and Throughput.

Your background in IT infrastructure has likely given you a strong intuition for these concepts in the context of network hardware. A network switch has a certain latency for each packet and a maximum throughput it can handle. In software architecture, we apply the same thinking to applications, services, and APIs.

Let's break these down with more precision.

Latency: The "How Fast"

Latency is the time it takes to complete a single operation. It's the response time a user experiences.

To understand how latency is measured and what contributes to it, let's watch a short video.

Key takeaways on latency:

• It's a Sum of Delays: Latency isn't just the network travel time. It's the full round-trip time, including the time the server spends processing the request (deserializing data, running business logic, querying databases, etc.). As an architect, you have more control over processing latency than network latency.
• Measure with Percentiles: A simple "average latency" can be misleading because it hides outliers. A system with a 200ms average latency might be great for most users but unacceptably slow for 5% of them. This is why we use percentiles:
  • p50 (Median): 50% of requests are faster than this value. This represents the typical experience.
  • p95: 95% of requests are faster than this value. This is a good measure of a consistently good experience.
  • p99 / p99.9: 99% (or 99.9%) of requests are faster than this value. This helps you understand the "worst-case" experience and is crucial for setting Service Level Objectives (SLOs) and alerting thresholds.

Throughput: The "How Much"

Throughput measures the system's capacity—how many operations it can handle in a given time period.

Let's return to the video to see how throughput is defined and scaled.

Key takeaways on throughput:

• It's a Rate: Throughput is measured as a rate, most commonly Requests Per Second (RPS) for web services or Transactions Per Second (TPS) for business systems.
• It's About Capacity: Your system must be architected to handle the expected peak throughput. If your e-commerce site needs to handle 1000 orders per minute during a sale, your architecture must support a throughput of at least ~17 TPS for the ordering service.
• Scaling Throughput: As the video shows, you can increase throughput by adding more resources. This is where your infrastructure background is highly relevant. However, the software must be designed to leverage those resources (e.g., through statelessness, which we'll cover later).

The Performance Trade-off

Optimizing for low latency and high throughput can sometimes be conflicting goals. Understanding this tension is a core architectural skill.

For example, a system designed for high throughput might use batching—collecting 100 database writes and executing them in one go. This is highly efficient and increases the total number of writes per second (throughput). However, the first write in the batch has to wait for the other 99, increasing its individual latency.

Conversely, a system designed for ultra-low latency might dedicate specific CPU cores to a single request, ensuring it's processed immediately. This reduces latency but lowers the total number of requests the system can handle concurrently (throughput).

Deep Dive: Scalability

Scalability is a system's ability to handle a growing amount of work by adding resources. It's related to performance but distinct. A system can be fast with 10 users but fall over with 1000. A scalable system can handle 1000 users (and more) by adding resources cost-effectively.

Let's watch a short video that explains this concept clearly.

Key takeaways on scalability:

• The Goal: To handle increased load without degrading performance. On a performance graph, we want to "push the knee" of the curve as far to the right as possible.
• Vertical Scaling (Scale Up): Making a single server more powerful (more CPU, RAM). It's simple but has physical and cost limits. You can only buy so big of a machine.
• Horizontal Scaling (Scale Out): Adding more servers to a pool of resources. This is the foundation of modern cloud architecture. It's more complex (requiring things like load balancers) but offers near-infinite scalability and better fault tolerance. To enable horizontal scaling, the software application must typically be stateless. We will explore this concept in depth later.

Other Key Attributes: Reliability and Availability

While we've focused on performance and scalability, let's briefly define two other critical attributes you'll encounter constantly.

• Reliability: The probability that a system will perform its intended function correctly for a specified period under stated conditions. It's about correctness and fault tolerance. A key metric is Mean Time Between Failures (MTBF). An idempotent API, which can be called multiple times with the same parameters without changing the result beyond the initial call, is a hallmark of a reliable system.
• Availability: The percentage of time a system is operational and able to respond to requests. It's about uptime. This is famously measured in "nines."
  • 99.9% ("three nines"): ~43 minutes of downtime per month.
  • 99.99% ("four nines"): ~4 minutes of downtime per month.
  • 99.999% ("five nines"): ~26 seconds of downtime per month.

Achieving higher availability requires more redundancy (e.g., multiple servers, data centers) and thus comes at a higher cost.

Conclusion

In this lesson, we introduced the concept of quality attributes as measurable goals that drive architectural design.

Key Takeaways:

• Quality attributes (or NFRs) define how well a system should operate.
• Performance is a measure of speed and capacity, quantified primarily by latency (measured in percentile response times like P99) and throughput (measured in rates like RPS/TPS).
• Scalability is a system's ability to handle increased load. The primary strategies are vertical scaling (bigger machines) and horizontal scaling (more machines).
• These attributes are often in competition, forcing the architect to make conscious trade-offs based on business priorities.

You now have a vocabulary to describe and measure the "goodness" of an architecture. This is the first step toward making deliberate, defensible design decisions.

In our next lesson, we will formalize this idea of balancing competing goals by exploring the concept of trade-offs in architectural decisions. We'll discuss how to prioritize these attributes and justify your choices—a skill that is absolutely essential for an aspiring architect.