Skip to content
Software Architecture Guide

Quality Attribute Trade-off

Explanation

Section titled “Explanation”

A quality attribute is a property such as security, speed, or reliability (see the article Quality Attribute). A trade-off means a design choice helps one quality and hurts another. Security choices, for example, can affect reliability, cost, or performance.

Common conflicts

  • Security versus performance. Inspection, identity checks, and encryption add delay and use computing power.
  • Performance versus security. Skipping slow steps, such as encryption or scanning, speeds things up but can weaken security. This needs a thorough risk analysis.
  • Caching versus fresh security state. Caching serves a stored copy instead of checking again. That is faster, but the copy can be stale.
  • Performance versus simplicity. Denormalizing data means storing it in several shapes for faster access. All copies must then stay in sync. Sharding adds similar complexity.
  • Security versus usability. A heavy focus on security can hurt how easy a system is to use. This is a particular problem in IoT (internet-connected devices).
  • Distribution. Splitting a system into many services, as in microservices, brings benefits. It also brings costs, such as weaker consistency and a need for operational maturity.

Tactics help some qualities and hurt others. A tactic is a proven design technique for one quality (see Architectural Tactic). Tactics that raise reliability and security can lower performance. Intrusion detection is one example. Architects must balance protection against efficiency.

How to handle trade-offs

  • Rank quality requirements by importance to stakeholders. Separate the top goals from lesser ones whose partial failure creates no high risk.
  • Do not treat decisions as one-time events. If you can test and change a design cheaply, a wrong choice carries less risk. This favors improving the design iteratively over analyzing everything up front.
  • Weigh the cost of coordination. Central coordination is worth its cost only in some cases.

Example

Section titled “Example”

A team builds a patient portal. They encrypt all traffic and check identity on every request. Pages load more slowly. To speed things up, they cache access decisions for a short time. Now a revoked user may keep access briefly. The team writes down both effects, ranks security above speed, and tests the cache duration before settling on it.

Trade-offs

Section titled “Trade-offs”

Weighing trade-offs takes effort, and the tools are limited. Few explicit guidelines help architects consider tactic trade-offs, and existing analysis is mostly qualitative. Trade-off information is crucial for decisions, yet existing approaches do not cover tactic trade-offs comprehensively. How to quantify these interactions and classify them systematically remains an open question.

Checks

Section titled “Checks”
  • Quality requirements are ranked by stakeholder importance, with top goals separated from lesser ones.
  • Each major decision names the quality it improves and the quality it may harm.
  • Performance shortcuts that bypass security steps are backed by a documented risk analysis.
  • Caching decisions state how stale data affects security.
  • The document shows how the design can be tested and changed over time.
Section titled “Related”

Sources

Section titled “Sources”