Quality Attributes

What Quality Attributes Are

Quality attributes (the “-ilities”) are the vocabulary of NFRs — the specific, measurable properties a design must deliver. They matter because every architecture diagram is secretly a bet about which attributes win. Making the bets explicit is what separates design from box-drawing.

The Core Set

Attribute	Definition	Measured by	Typical target
Availability	Fraction of time service responds correctly	Uptime / error-rate SLO	99.9%–99.99%
Latency	Time to serve one request	p50/p95/p99	Sub-100ms reads common
Scalability	Ability to handle growth by adding resources	QPS at target latency vs nodes	Linear-ish scaling
Reliability	Probability of correct operation over interval; resistance to failure	MTBF, error budget burn	Zero silent data loss
Durability	Data survives despite failures	Replication factor, backup RPO	11 nines with erasure coding
Consistency	How tightly replicas agree	Staleness bounds, anomaly class	Per-data-type choice
Security	Resistance to unauthorized access/change	Threat model coverage, audit	Least privilege everywhere
Maintainability	Cost to change safely	Change lead time, defect rate	Boring, documented, tested

Attributes Conflict — That Is Their Whole Point

                    STRONG CONSISTENCY
                          ▲
                          │  sync replication:
                          │  every write waits for quorum
        DURABILITY ◄──────┼──────► LATENCY
                          │  async replication:
                          │  fast writes, divergence window
                          ▼
                   LOW WRITE LATENCY

 AVAILABILITY ◄── retries+redundancy cost money ──► COST
 SCALABILITY  ◄── sharding breaks global txns ──► CONSISTENCY

Each arrow is a real engineering decision. Naming which corner you are standing in — and why this feature belongs there — is senior-level communication.

Scenario Format: Making Attributes Testable

Vague targets (“fast”, “reliable”) cannot steer design. The scenario format pins each attribute:

 ATTRIBUTE:  Latency
 STIMULUS:   User requests feed page
 RESPONSE:   Fully rendered first screen
 MEASURE:    p95 under 200 ms
 CONDITIONS: 10M DAU, cache hit ratio 90%, any region
 
 ATTRIBUTE:  Durability
 STIMULUS:   AZ loss during peak write traffic
 RESPONSE:   Zero acknowledged writes lost
 MEASURE:    RPO = 0 for payment records

Now the architecture can be checked against requirements instead of argued about.

Choosing Which Attributes Matter

Not every system needs every attribute maximized — ranking is the actual work:

1. Identify the money path — checkout, ride-match, trade-execution get strictest latency + consistency.
2. Identify the brand path — login, search, feeds get availability + tail-latency focus.
3. Let the rest be cheap — admin panels at 99% availability on boring tech.

A system where everything is P0 has no architecture, only anxiety.

Interview Framing

Strong candidates declare attribute priorities in the requirements phase (“reads are latency-sensitive and loss-tolerant; payments are the opposite”) and then visibly honor those rankings when choosing components. Revisiting the ranking under interviewer pushback (“what if durability must be absolute?”) demonstrates the thinking, not just the conclusion.