In our previous discussion, we broke down the difference between functional and non-functional requirements. To put it simply: if functional requirements answer the question, “What does the system do?” then non-functional requirements tackle something much more critical: “How does the system behave?”
In the world of system design, we call these behavioral traits Quality Attributes. Think of them as the report card we use to judge whether an architecture is actually good. We’re moving past just listing features; we’re talking about whether the system is fast, scalable, secure, observable, and—most importantly—cost-effective.
What Exactly is a Quality Attribute?
At its core, a quality attribute is an indicator of health. It helps us answer the anxieties of both engineering and business teams: “Is it laggy? Will it crash if our traffic 10x’s tomorrow? If one server goes down, does the whole app follow suit?”
People often confuse non-functional requirements with quality attributes. Here’s the easiest way to separate them: a Quality Attribute is the category (e.g., Performance), while a Non-functional Requirement is the specific target (e.g., “The search API must have a p95 latency under 500ms”). One is the label; the other is the measurable goal.
Why It Matters: One Feature, Two Very Different Worlds
Imagine two companies building a “Messaging” feature. On paper, they do the exact same thing. But look at the requirements behind the scenes:
- System A: Built for a small group of users. Messages can be delayed by a few seconds, and message history isn’t a priority.
- System B: Must deliver messages in milliseconds, handle millions of concurrent connections, and ensure zero data loss—even when users are offline.
Even though the “feature” is identical, the architecture will be worlds apart. System A might survive on a basic backend and a single database. System B? You’re looking at connection servers, durable storage, retry mechanisms, and a complex scaling strategy. This is why quality attributes are the true drivers of architectural decisions.
The Core Constraints That Actually Shape Your Design
When we sit down to review a design, we’re not just looking for “good code.” We’re looking for how the system handles specific constraints. These are the attributes that force you to change your architecture from a simple monolith to something more complex:
- Scalability & Throughput: This is about more than just “handling growth.” It’s about how the system behaves under pressure. Can your database handle the write volume? Do you need to decouple services with a message queue to handle spikes?
- Availability vs. Reliability: People use these interchangeably, but they aren’t the same. Availability is about the system being “up.” Reliability is about the system being “correct.”
- Observability & Debuggability: If you can’t see what’s happening inside your production environment, your design is incomplete. You need structured metrics and tracing.
- Cost & Resource Efficiency: Every architectural decision has a price tag. A senior engineer knows how to meet SLOs without wasting the company’s cloud budget.
Stop Using Vague Words
If I hear an engineer say “The system needs to be fast,” I immediately ask: “Define fast.”
Vague goals lead to bad designs. “Fast” means nothing. “p95 latency under 200ms” means everything. Why p95? Because the average (mean) is a lie—it hides the 5% of users who are having a terrible, slow experience. Make your attributes measurable, or don’t bother listing them at all.
What’s your "must-have" attribute?
I've found that teams often over-index on scalability while completely ignoring observability until something breaks in production.
I’m curious—which quality attribute do you think is most often neglected in early-stage designs? And what’s the most painful trade-off you’ve had to make recently? Let’s discuss in the comments!
Top comments (0)