Quality Attributes and Constraints

11 min read · Updated 2026-04-25

Quality attributes are the non-functional characteristics that define how well a system performs its intended functions. Combined with the constraints around the system, they shape every architectural decision worth talking about.

This lesson is the working vocabulary: the named quality attributes you’ll see referenced throughout the course, and the constraints that bound how far you can push them.

Performance

Definition. How efficiently the system uses resources to meet timing requirements.

Latency

Time to process a single request.

Throughput

Requests handled per unit of time.

Resource utilization

CPU, memory, network, I/O efficiency.

Common levers: caching frequently used data, async processing for long ops, connection pooling, query optimization, CDN for static assets.

Availability

Definition. Percentage of time the system is operational and serving requests.

99%

baseline

~3.65 days/yr down

99.9%

standard

~8.76 hours/yr

99.99%

critical

~52.6 minutes/yr

99.999%

carrier

~5.26 minutes/yr

Each level dramatically more expensive than the last.

High availability requires redundancy, fault detection, graceful degradation, reliable monitoring.

Scalability

Definition. Ability to handle increased load without architectural surgery.

Horizontal scaling

More machines

Best fit for stateless services. Distributes load, improves fault tolerance, gives elastic capacity.

Vertical scaling

Bigger machines

Best fit for stateful services with moderate growth. Simpler to implement, eventually hits hard limits.

Scaling problems to plan for:

Data consistency

Keeping information correct across nodes during concurrent reads/writes.

Session management

Preserving UX in stateless architectures behind load balancers.

Coordination complexity

Making multiple components and services behave coherently.

Security

Five principles cover most architecture-level security thinking:

Step 01

Least privilege

Grant the minimum permissions necessary.

Step 02

Security by design

Build it in from the start, not bolted on later.

Step 03

Defense in depth

Multiple independent layers of protection.

Step 04

Fail secure

When something goes wrong, default to safe.

Step 05

Zero trust

Verify everything — even inside your own network.

The architectural toolkit:

Authentication & Authorization

OAuth/OIDC, JWT, mTLS. RBAC or ABAC.

Input validation

Validate and sanitize all incoming data.

Encryption

AES-GCM at rest, TLS 1.3 in transit, properly rotated keys.

Audit logging

Comprehensive logs for monitoring and incident response.

Reliability

Definition. Probability the system operates correctly over a specified time period.

MTBF

Mean Time Between Failures.

MTTR

Mean Time To Repair (or Recover).

Availability

Percentage of time operational.

Practical patterns: redundancy, checkpoints, error detection, comprehensive testing.

Modifiability

Definition. How easily and safely the system can be changed.

Clear interfaces

Well-defined contracts between components.

Loose coupling

Minimal interdependencies between components.

Separation of concerns

Each component has one clear responsibility.

Modifiability is what determines whether the system is evolvable (last lesson) or stuck. The lessons reinforce each other.

Testability

Definition. How easily the software can demonstrate its faults through testing.

Dependency injection

Swap real components for mocks during testing.

Separation of concerns

Clean responsibility boundaries make individual components easy to test.

No global state

Predictable behaviour without hidden dependencies.

Clear interfaces

Well-defined contracts make scenarios easy to write.

Usability

Usability has architectural implications even though it’s often considered “just UI.”

Interface design

Intuitive controls, logical navigation, visual hierarchy.

Responsiveness

Quick response times, smooth transitions, immediate feedback.

Error handling

Clear messages, suggestions for resolution, graceful degradation.

Interoperability

The ability of systems to work together across platforms, technologies, and organizational boundaries.

API integration

Standardized formats and protocols.

Data exchange

Across different storage formats and schemas.

Platform compatibility

Across diverse technology stacks.

Version management

Backward compatibility and graceful interface evolution.

Portability

Definition. How easily the system can be moved between environments.

Standard APIs

Generally accepted interfaces, not proprietary lock-in.

Containerization

Consistent deployment across environments.

Abstraction layers

Isolate platform-specific code.

Multi-cloud capability

When business needs justify it.

Quality Attributes Pull Against Each Other

Common tensions:

If you push…	You usually pay in…
Security	Performance (encryption, validation overhead)
Availability	Complexity (redundancy, failover)
Scalability	Strict consistency (distributed systems trade it away)
Performance	Maintainability (specialized optimizations)

Constraints

Constraints are the limits inside which architecture has to operate. Not obstacles — context that makes a particular design correct for this system.

Infrastructure constraints

Hardware constraints

CPU, memory, storage. Drives caching, efficient algorithms, careful data layout.

Network constraints

Bandwidth limits drive payload optimization, compression, batching, edge caching.

Platform constraints

Whatever the chosen stack rules out (language ecosystems, cloud-specific services).

Regulatory constraints

These often dictate hard architectural decisions:

GDPR

Actually purge personal data from backups, logs, derived datasets — not just mark deleted.

HIPAA

Healthcare-specific authentication and access-control requirements. Affects access patterns and audit logging.

SOX

Financial change control and segregation of duties. Affects deployment processes and system boundaries.

PCI DSS

Credit card data isolation, encryption, monitoring. Often pushes toward tokenization.

SOC 2

Security, availability, integrity, confidentiality, privacy controls.

Organizational constraints

Budget

Affects infrastructure and tech choices.

Time-to-market

Forces conscious technical trade-offs.

Team skills

Limit viable technology choices.

Team structure

Defines architecture through Conway's Law.

A practical example of Conway’s Law:

Functional teams

Frontend / backend / DBA specialists

Tend to produce layered architectures with clear technology boundaries. Deep technical expertise; slower cross-functional features.

Product teams

Full-stack, organized by business capability

Tend to produce service-oriented architectures with full ownership. Faster feature delivery; can duplicate work between teams.

A Systems View

Quality attributes and constraints together form the foundation of all architectural decisions. The skill is understanding that they work as a system — push one and others move.

Both qualities and constraints change over time. Anticipate the changes. Design systems that can adapt their priorities and creatively work within shifting limits.

Recap

Quality attributes describe how well the system works: performance, availability, scalability, security, reliability, modifiability, testability, usability, interoperability, portability.
Each has named techniques and common levers. Knowing the vocabulary helps you have precise conversations.
Quality attributes pull against each other. Optimize for the right ones for this system.
Constraints — infrastructure, regulatory, organizational — are the context inside which architecture has to live.
Constraints aren’t obstacles; they’re inputs to good design.
Both qualities and constraints change over time. Build systems that can re-prioritize as the business evolves.