# Quality Attribute Trade-off **In short:** Improving one quality of a system usually costs another. Architects weigh these conflicts, rank what matters most to stakeholders, and improve the design step by step. ## 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 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 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 - 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. ## Related - [Quality Attribute](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute.md) - [Architectural Tactic](https://arc.fuet.ch/concepts/tactics/architectural-tactic.md) - [Trade-off Point](https://arc.fuet.ch/concepts/evaluation/trade-off-point.md) - [Tactic Trade-off Balancing](https://arc.fuet.ch/concepts/tactics/tactic-trade-off-balancing.md) - [Quality Attribute Prioritization](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute-prioritization.md) - [Architecture Tradeoff Analysis Method (ATAM)](https://arc.fuet.ch/concepts/evaluation/architecture-tradeoff-analysis-method-atam.md) - [Security](https://arc.fuet.ch/concepts/quality-attributes/security.md) - [Performance Efficiency](https://arc.fuet.ch/concepts/quality-attributes/performance-efficiency.md) ## Sources - [Security tradeoffs - Microsoft Azure Well-Architected Framework | Microsoft Learn](https://learn.microsoft.com/en-us/azure/well-architected/security/tradeoffs) — learn.microsoft.com, accessed 2026-11-09 - [General design principles - AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/general-design-principles.html) — docs.aws.amazon.com, accessed 2026-11-09 - [10 - Quality | arc42 Documentation](https://docs.arc42.org/section-10/) — docs.arc42.org, accessed 2026-11-08 - [Performance Efficiency tradeoffs - Microsoft Azure Well-Architected Framework | Microsoft Learn](https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/tradeoffs) — learn.microsoft.com, accessed 2026-11-09 - [Enabling Design of Secure IoT Systems with Trade-Off-Aware Architectural Tactics - PMC](https://pmc.ncbi.nlm.nih.gov/articles/PMC11598420/) — pmc.ncbi.nlm.nih.gov, accessed 2026-11-09 - [Software Architecture Guide](https://martinfowler.com/architecture/) — martinfowler.com, accessed 2026-11-09