What are sensitivity points and trade-off points in an architecture, and why do they matter when evaluating a significant decision?
answer
- sensitivity = one attribute moves
- trade-off = two attributes conflict
- risk vs non-risk (with assumptions)
- ATAM scenario walkthrough
- record what you sacrificed
basics
~20 sA sensitivity point is a decision where changing it noticeably moves one quality attribute, such as response time. A trade-off point is a decision that moves two or more quality attributes in opposite directions, so you must consciously choose which one to favour.
solid answer
~50 sThese come from architecture evaluation, notably ATAM. A sensitivity point is a property of a component or decision — a replication factor, a cache expiry, a thread-pool size, a boundary placement — for which a small variation produces a significant change in one quality-attribute response. A trade-off point is a sensitivity point shared by two or more attributes that respond in conflicting directions: synchronous replication raises durability and consistency but hurts write latency and availability under partition; an extra authorisation hop raises security but costs latency; finer-grained services raise deployability and team autonomy but hurt end-to-end latency and operational complexity. Evaluation walks prioritised quality-attribute scenarios against the design, records the sensitivity and trade-off points, and classifies each outcome as a risk or a non-risk. This matters because architecturally significant decisions are almost always trade-off points: the deliverable is an explicit, recorded statement of which attribute was sacrificed and why, plus the measurement that would prove the choice wrong.
go deeper
Give the definitions plus one clear example, such as caching improving speed at the cost of stale data.
Distinguish the two precisely, list several canonical trade-off points, and explain that you pick the position from prioritised quality scenarios rather than in the abstract.
Add the evaluation mechanics (scenario walkthrough, risks and non-risks, assumptions), parameterising numeric sensitivity points, and enforcing the chosen position with automated fitness functions and monitoring.
Frame trade-offs as business decisions requiring stakeholder agreement, connect risk themes back to business goals, discuss assumption expiry and periodic re-evaluation, and challenge false trade-offs by investing to move the frontier.
## Vocabulary These terms are standard in **ATAM** (Architecture Trade-off Analysis Method), a scenario-based evaluation method from the SEI, but the concepts apply to any architecture review. - **Quality attribute**: a measurable system property — latency, throughput, availability, durability, security, modifiability, testability, cost. - **Sensitivity point**: a decision or parameter where a change produces a significant change in a quality-attribute response. Formally, the attribute measure is sensitive to that decision. - **Trade-off point**: a sensitivity point affecting **two or more** attributes that move in **opposite** directions. You cannot maximise both; you choose a position. - **Risk**: a decision (or an absent decision) that plausibly prevents an important scenario from being met. - **Non-risk**: a decision that is sound *given stated assumptions* — worth recording, because if an assumption changes, the non-risk becomes a risk. - **Risk theme**: a pattern across several risks pointing at a systemic weakness, usually traceable to a business goal. ## Why they are the heart of significant decisions A decision that moves nothing is not significant. A decision that improves exactly one attribute and harms nothing is easy — just do it. The genuinely hard, genuinely architectural decisions are trade-off points, and their significance comes precisely from the fact that someone must decide which quality loses. ## Canonical trade-off points - **Consistency vs availability/latency** — synchronous cross-region replication improves durability and consistency, costs write latency and availability during partitions. - **Granularity of decomposition** — smaller services improve independent deployability, fault isolation and team autonomy; they cost network hops, end-to-end latency, transactional simplicity and operational surface. - **Caching** — improves latency and load; costs freshness, correctness edge cases and invalidation complexity. - **Security controls** — encryption, token validation and extra authorisation hops improve confidentiality; cost latency, complexity and sometimes availability (a failing auth service takes everything down). - **Abstraction/indirection layers** — improve modifiability and portability; cost performance, cognitive load and debuggability. - **Redundancy** — improves availability; costs money and, if implemented as active-active writes, correctness complexity. ## How to find them 1. Take the prioritised quality-attribute scenarios (the ASRs). 2. Walk each scenario through the candidate design, naming which decisions the response depends on. 3. Any decision appearing in the reasoning for a scenario's response is a sensitivity point for that attribute. 4. Any decision appearing in two scenarios where improving one worsens the other is a trade-off point. 5. Record each as a risk or a non-risk, with the assumptions that make it so. ## Practical use beyond formal reviews - **Argument structure**: instead of "we chose X because it is better," write "X is a trade-off point between availability and consistency; we favour availability because scenario A (high importance) tolerates 5-second stale reads while scenario B tolerates no downtime." - **Parameterise, do not hard-code**: numeric sensitivity points (timeouts, pool sizes, replication factors, cache TTL) should be configurable and load-tested — that is exactly where tuning pays. - **Monitoring**: instrument the measures at your trade-off points; they are where the system first drifts out of its intended envelope. - **Fitness functions**: encode the chosen position as an automated check (a latency budget test, a chaos experiment, a dependency rule) so future changes cannot silently move the trade-off. ## Edge cases and cautions - **Assumption drift**: a non-risk holds only under its assumption ("traffic stays under 2k requests/second"). When the assumption expires the trade-off must be revisited — which is why assumptions belong in the decision record. - **Hidden trade-off points**: some appear only under failure or load (a retry policy is harmless until a downstream slowdown turns it into a self-inflicted denial of service). - **False trade-offs**: sometimes better engineering removes the conflict entirely (a smarter data layout gives both speed and simplicity). Do not accept a trade-off before checking whether the frontier can be moved.
- How do you record a trade-off decision so it survives team turnover?An Architecture Decision Record: context (the conflicting scenarios and their priorities), the options considered, the decision, the quality attribute deliberately sacrificed, the assumptions that justify it, and the observable measure that would signal the decision has gone stale. Link it to the automated check that enforces the chosen position.
- What is the practical difference between a risk and a non-risk in an architecture evaluation?A risk plausibly prevents an important scenario from being met and needs mitigation. A non-risk is a decision that works given explicit assumptions; it is recorded because when those assumptions change — traffic grows, regulation shifts — the non-risk silently becomes a risk.
Camera settings. Shutter speed is a sensitivity point for motion blur. Aperture is a trade-off point: open it and you gain light but lose depth of field. A photographer does not hunt for the 'best' aperture — they choose a position based on the shot they need, exactly as an architect chooses based on the prioritised scenarios.
saying these in an interview costs you the question
- Presenting an architecture as strictly better without naming what it sacrifices
- Confusing sensitivity points (one attribute) with trade-off points (conflicting attributes)
- Recording decisions without the assumptions that justify them, so nobody knows when to revisit
- Assuming trade-offs are permanent — sometimes better design removes the conflict
- Analysing only the happy path; many trade-off points appear only under load or failure