skip to content

Quality Attributes

9 roadmaps6 questions

Scalability, availability, reliability, maintainability, security and performance are what actually drive architecture, and they conflict. You will learn to write quality-attribute scenarios that turn a vague wish for fast into something testable, and to name the trade-offs each choice forces.

part ofSoftware design & architectureoverview, primer and where to startread it →
on this pageshow

explore

questions

6

What is a quality attribute (non-functional requirement) in software architecture, and how does it differ from a functional requirement?

level: juniorimportance: must knowfreq 78%

answer

  1. FR = what; QA = how well
  2. QAs are the architectural drivers
  3. Unmeasurable = not a requirement
  4. Constraints ≠ quality attributes
  5. They conflict: budget, not checklist

basics

~20 s

A functional requirement says WHAT the system does ("users can reset a password"). A quality attribute says HOW WELL it does it — fast, available, secure, maintainable. Quality attributes shape the architecture; functions can usually be implemented in many architectures.

solid answer

~50 s

Functional requirements describe behaviour: given an input, what output or state change is produced. Quality attributes (also called non-functional requirements, NFRs, or "-ilities") describe qualified properties of that behaviour: performance (latency, throughput), availability, reliability, scalability, security, maintainability/modifiability, testability, usability, observability, portability, cost. The practical distinction is architectural leverage. Almost any function can be built on almost any structure — you can implement "reset password" in a monolith or in microservices. But quality attributes are what force structural choices: a 99.99% availability target forces redundancy and failover; a strict modifiability target forces module boundaries and stable interfaces; a low-latency target may forbid a network hop. That is why quality attributes are called architectural drivers. They are also cross-cutting and mutually antagonistic: adding replicas raises availability but complicates consistency; adding caching cuts latency but risks staleness. So they must be stated measurably and prioritized, not just listed.

go deeper

for a junior

Define both terms, give one or two clear examples of each, and say that quality attributes describe how well the system does its job. Mention that "fast" needs a number.

for a middle

Add that quality attributes are the architectural drivers, list five or six with their measures, and name the scenario template (stimulus / environment / response / response measure) as the way to make them testable.

for a senior

Lead with the trade-off framing: quality attributes conflict, so the deliverable is a prioritized, measured set plus the tactics chosen to satisfy the top ones. Give a real conflict you resolved and the evidence you used.

for a principal

Frame it as stakeholder economics and risk: turn business goals into a utility tree, expose sensitivity and trade-off points, tie targets to error budgets and cost, and set up the organization to keep measuring them (SLOs, fitness functions) rather than deciding once.

## The two kinds of requirements **Functional requirement (FR)** — a statement about *what* the system must do. It is verified by asking "did the right thing happen?" - "A user can request a password reset link." - "An order over the free-shipping threshold ships free." **Quality attribute (QA)**, a.k.a. non-functional requirement (NFR) or "-ility" — a statement about *how well*, *under what conditions*, and *at what cost* the system does it. It is verified by measurement. - "95% of password-reset emails are sent within 5 seconds under 500 requests/second." - "The order service stays available during the loss of one availability zone." There is a third category worth naming: **constraints** — decisions handed to you rather than derived ("must run on-premises", "must use the existing Oracle licence", "must comply with GDPR"). Constraints are non-negotiable inputs; quality attributes are negotiable targets. ## Why quality attributes are the architectural drivers Architecture = the set of structures (modules, components/connectors, allocation to hardware) plus the decisions that are expensive to change later. - **Functionality is largely independent of structure.** "Send an email" can live in a monolith, a serverless function, or a dedicated service. The feature works in all three. So functionality alone rarely tells you what to build. - **Quality attributes discriminate between structures.** If you need failover in under 30 seconds, you need redundancy, health checking, and state replication — that is structure. If you need to swap payment providers in a two-week sprint, you need an anti-corruption layer / provider-agnostic port — that is structure. If you need 2 ms p99 in-process reads, you cannot put a network call on the hot path — that removes structures from the table. The standard formulation: **architecture is driven by the quality attributes, the constraints, and a small set of architecturally significant functional requirements (the ones that stress the structure).** ## The common quality attributes, defined | Attribute | Plain definition | Typical measure | |---|---|---| | **Performance** | How quickly work is done | latency percentiles (p50/p99), throughput (req/s), resource utilization | | **Scalability** | Ability to absorb increased load by adding resources | cost/throughput curve; linearity; max load at fixed latency | | **Availability** | Fraction of time the system is usable | uptime % ("nines"), successful-request ratio, error budget | | **Reliability** | Ability to run without failing / to produce correct results | MTBF, failure rate, data-loss (RPO) | | **Security** | Resistance to misuse; confidentiality, integrity, availability of data | time-to-detect, blast radius, authz coverage, audit completeness | | **Maintainability / Modifiability** | Cost and risk of changing the system | time & number of modules touched per change type | | **Testability** | Ease of demonstrating faults | % behaviour reachable by automated tests, test runtime | | **Deployability** | Ease and safety of shipping | lead time, deploy frequency, change-failure rate, rollback time | | **Observability** | Ability to ask new questions about production state | MTTD (time to detect), coverage of logs/metrics/traces | | **Usability / Accessibility** | Ease of human use | task success rate, WCAG level | | **Interoperability / Portability** | Working with, or moving to, other systems/platforms | effort to add an integration or change cloud | | **Cost / efficiency** | Money and energy per unit of work | $ per 1k requests | Note several of these are *development-time* qualities (maintainability, testability, deployability) rather than *runtime* qualities. Both count; development-time qualities are the ones teams most often silently trade away. ## Why "non-functional" is a slightly bad name Two objections you can voice in an interview: 1. Quality attributes are absolutely realized by *functions* — an availability target is implemented by health checks, retries, failover logic, which are code. 2. The name invites treating them as optional garnish ("we'll add performance later"). In practice, retrofitting availability or modifiability is a rewrite. Prefer the term **quality attribute** or **architectural driver**. ## They must be measurable, or they are not requirements "The system shall be fast/scalable/secure/user-friendly" is untestable and unfalsifiable — everyone nods, nothing is decided. The industry fix is the **quality-attribute scenario**: source of stimulus, stimulus, artifact, environment, response, response measure. E.g. "When traffic triples over 10 minutes (stimulus) on the checkout service in normal production (environment), the system autoscales (response) so that p99 checkout latency stays under 800 ms and no requests are dropped (measure)." Now you can test it, and later argue about it with data. ## They conflict — that is the whole job Quality attributes are not a checklist to maximize; they are a budget to allocate. - Availability ↑ via replication → consistency ↓ or latency ↑ (this is the CAP/PACELC family of trade-offs). - Performance ↑ via caching/denormalization → freshness ↓, maintainability ↓. - Security ↑ via encryption, extra hops, MFA → latency ↑, usability ↓. - Modifiability ↑ via indirection and layers → performance ↓, and sometimes comprehensibility ↓. - Scalability ↑ via statelessness and sharding → operational complexity and cost ↑. So the architect's output is not "all attributes high" but an explicit, ranked, measured set of targets and the decisions that satisfy the top ones while accepting known degradation in the rest. ## How this shows up in an interview Good answer shape: define both terms, say why QAs (not features) drive structure, give two or three named attributes with *measures*, and finish with one concrete conflict you have personally traded off. Naming the scenario template and one trade-off (e.g. cache staleness vs latency) is what separates a junior answer from a middle one.

  • Give an example where the same functional requirement leads to two completely different architectures.
    "Show a user's account balance." If the requirement is p99 < 50 ms at 100k req/s with eventual consistency acceptable, you serve it from a replicated read cache/materialized view. If the requirement is that the number must be strictly correct at read time (regulatory), you read from the authoritative ledger under a transaction and accept higher latency and lower availability during partitions. Same feature, opposite structures — driven purely by quality attributes.
  • Are constraints the same as quality attributes?
    No. A constraint is a pre-made decision you must live with (platform, language, budget, legal regime, an existing system you must integrate with). A quality attribute is a target you can negotiate and trade off. Constraints prune the design space before you start; quality attributes let you choose within what remains.
  • Which quality attributes are hardest to retrofit?
    Availability, security, scalability, and modifiability — all of them are properties of the structure itself. Retrofitting availability means adding redundancy and removing hidden single points of state; retrofitting security means re-doing trust boundaries; retrofitting modifiability means re-cutting module boundaries. By contrast, a missing feature is usually additive.

A house's functional requirements are "has three bedrooms and a kitchen". Its quality attributes are "survives an earthquake, heats for under $100/month, and can have a fourth bedroom added without moving the plumbing". Any builder can give you three bedrooms; only the structural decisions — foundation, load-bearing walls, where the pipes run — decide the rest, and they are the ones you cannot change afterwards without demolition.

saying these in an interview costs you the question

  • Calling quality attributes "optional" or "something we add after the features work" — availability and modifiability are structural and cannot be bolted on.
  • Stating an attribute with no measure ("must be fast/scalable/secure") and treating it as a requirement.
  • Confusing constraints (platform, legal, budget) with negotiable quality-attribute targets.
  • Claiming all quality attributes can be maximized simultaneously, with no acknowledgement of conflicts.
  • Listing only runtime attributes and forgetting development-time ones like maintainability, testability, and deployability.
  • Equating ACID's consistency or 'quality' in general with the specific technical definitions used for architectural drivers.

context

resolving links…

open as a page

What is the difference between availability and reliability as quality attributes, and how do MTBF and MTTR relate to the "nines"?

level: middleimportance: must knowfreq 62%

basics

~20 s

Reliability = how rarely it breaks. Availability = how much of the time it is usable. Availability ≈ MTBF / (MTBF + MTTR), so you can raise it either by failing less often or by recovering faster. "Three nines" = 99.9% ≈ 43 minutes down per month.

open as a page

A stakeholder writes the requirement "the system must be scalable". How do you turn that into something an architect can design and test against?

level: middleimportance: must knowfreq 55%

basics

~20 s

Rewrite it as a concrete scenario with numbers: who or what triggers it, under what conditions, what the system should do, and the measurable limit. E.g. "When traffic triples in 10 minutes, p99 latency stays under 800 ms with no dropped requests."

open as a page

Explain the CAP theorem and its PACELC extension, and how they shape architectural decisions about consistency, availability, and latency.

level: seniorimportance: must knowfreq 72%

basics

~20 s

CAP: when the network splits a distributed system (a partition), you must choose between staying consistent (reject/block requests) or staying available (answer, possibly with stale data). PACELC adds: even with no partition, you still trade latency against consistency.

open as a page

How do latency, throughput, and tail latency (p99) differ as performance targets, and why can improving one make another worse?

level: seniorimportance: should knowfreq 52%

basics

~20 s

Latency is how long one request takes; throughput is how many complete per second. p99 (tail) is the slowest 1% — what unlucky users feel. Batching or queueing more work raises throughput but makes individual and tail latency worse.

open as a page

Stakeholders demand strong consistency, sub-100 ms latency, 99.99% availability, and fast delivery of new features — all at once. How do you prioritize conflicting quality attributes and make the trade-offs explicit?

level: principalimportance: should knowfreq 38%

basics

~20 s

You cannot maximize all of them, so make the conflict visible: turn each demand into a measured scenario, rank them by business value and risk with the stakeholders who own the money, then decide per user journey — not for the whole system — and write down what you gave up.

open as a page