Applied · Module 3
Quality attributes and trade offs
latency and throughput are easy to measure.
Previously
Integration and APIs
Systems talk in two main ways.
This module
Quality attributes and trade offs
latency and throughput are easy to measure.
Next
Data, state and consistency
State hides everywhere.
Progress
Mark this module complete when you can explain it without rereading every paragraph.
Why this matters
Someone proposes removing rate limits because it “hurts the user experience”.
What you will be able to do
- 1 Explain quality attributes and trade offs in your own words and apply it to a realistic scenario.
- 2 Quality attributes are trade-offs. Choose deliberately and measure what you care about.
- 3 Check the assumption "Qualities are measurable" and explain what changes if it is false.
- 4 Check the assumption "Trade-offs are recorded" and explain what changes if it is false.
Before you begin
- Foundations-level vocabulary and concepts
- Confidence with basic diagrams and section terminology
Common ways people get this wrong
- Optimising one axis. Optimising only for speed can destroy reliability and safety.
- Vague requirements. Vague requirements create rework and conflict.
Main idea at a glance
Trade-off map
Architectural quality is portfolio management across competing outcomes.
Stage 1
Business goal
Define the business outcome you are optimising for. Examples: user retention, cost efficiency, delivery velocity.
I think this step is often skipped in favour of jumping to technology choices.
latency and throughput are easy to measure. availability is about reliability. We cannot maximise everything at once.
Architects balance these qualities rather than chase perfection. A fast system that fails often is not success.
Worked example. “Secure” vs “usable” is a fake argument
Worked example. “Secure” vs “usable” is a fake argument
Someone proposes removing rate limits because it “hurts the user experience”. Another person proposes adding ten security checks to every request because “security is non-negotiable”. Both positions are lazy.
The real job is to design controls that are proportionate to risk and measured against outcomes. Example: rate limit the risky endpoints, add friction where harm is highest, and monitor for abuse.
Common mistakes in trade-off discussions
Trade-off mistakes to avoid
Trade-off discussions fail when teams avoid measurable language.
-
Treating quality attributes as opinions
Convert each quality goal into measurable thresholds before choosing architecture options.
-
Optimising one attribute in isolation
Evaluate end-to-end impact so local gains do not create systemic harm.
-
Ignoring operational cost
Include support burden, alert fatigue, and incident recovery cost in every design decision.
Verification. Make the trade-off explicit
Trade-off verification prompts
Ask these before final approval.
-
State optimisation target and sacrifice
Make explicit what you optimise for and what you accept in return.
-
Quantify failure cost and detection
Define business impact and the signals that reveal degradation quickly.
-
Prepare a rollback trigger
Write a clear rollback condition and the actions required if the decision underperforms.
Reflection prompt
Which quality attribute do you personally undervalue when you are under delivery pressure. What would force you to take it seriously.
Mental model
Quality attributes and trade-offs
Quality attributes are trade-offs. Choose deliberately and measure what you care about.
-
1
Qualities
-
2
Security
-
3
Performance
-
4
Reliability
-
5
Trade-off
Assumptions to keep in mind
- Qualities are measurable. If you cannot measure, you cannot manage.
- Trade-offs are recorded. Recording trade-offs prevents accidental reversal later.
Failure modes to notice
- Optimising one axis. Optimising only for speed can destroy reliability and safety.
- Vague requirements. Vague requirements create rework and conflict.
Key terms
- latency
- The time it takes for a request to receive a response.
- throughput
- How many requests a system can handle in a period.
- availability
- How often a system is able to serve requests.
Check yourself
Quick check. Quality attributes
0 of 7 opened
Why are trade offs unavoidable
Improving one quality often reduces another.
What does availability measure
How often the system can serve requests.
Scenario. Security proposes extra checks everywhere, product demands zero friction. What is the real job here
Make risk based trade offs explicit. Add friction where harm is highest, measure impact, and design controls that meet outcomes rather than slogans.
Why does latency matter
Slow responses reduce usability and trust.
What is a common quality conflict
Security checks can increase latency.
Why measure maintainability
Change becomes the main cost over time.
What should guide trade off choices
Business outcomes and risk appetite.
Artefact and reflection
Artefact
A one-page decision note with assumption, evidence, and chosen action
Reflection
Where in your work would explain quality attributes and trade offs in your own words and apply it to a realistic scenario. change a decision, and what evidence would make you trust that change?
Optional practice
Adjust priorities and see the balance shift.