Architecture reviews distinguish four kinds of finding: risks, non-risks, sensitivity points and trade-off points. Define each and explain why recording non-risks is worth the effort.
answer
- risk = decision → consequence → endangered goal
- non-risk = OK *because assumptions*
- sensitivity = one attribute swings
- trade-off = two attributes, opposite directions
- risks roll up into themes → business drivers
basics
~20 sA risk is a decision that may stop a goal being met; a non-risk is a decision that's fine given stated assumptions; a sensitivity point is a decision that strongly swings one quality attribute; a trade-off point swings two the opposite way. Non-risks record the assumptions that could later expire.
solid answer
~50 s**Risk**: a decision, or its absence, that endangers a quality attribute scenario — write it as decision → consequence → endangered goal ("a single shared database for all services means one bad query stalls checkout, endangering the 99.95% availability goal"). **Non-risk**: a decision judged acceptable *given explicit assumptions* ("caching sessions for 15 minutes is fine, assuming logout revocation is not required and peak is 5k rps"). **Sensitivity point**: a decision or parameter where a small change causes a large change in one attribute — the number of replicas versus availability. **Trade-off point**: a sensitivity point for two or more attributes moving in opposite directions — synchronous cross-region replication improves durability, worsens write latency. Non-risks matter because they capture the assumption in writing; when peak load triples or compliance demands instant revocation, the assumption is falsified and the non-risk automatically becomes a risk you can find by grepping the report.
go deeper
Define the four terms and give one clean example of each.
Show the decision → consequence → goal phrasing and explain how a non-risk turns into a risk when its assumption expires.
Give real trade-off pairs from systems you've built and describe how you decided and documented them (ADR, measured evidence).
Focus on the operating model: risk themes tied to business drivers and funding, sensitivity points promoted to SLOs/fitness functions, and periodic re-validation of non-risk assumptions.
## Why a vocabulary at all Without shared terms, review output collapses into an undifferentiated "concerns" list where a fatal single point of failure sits beside a naming nit. The four categories, standard in ATAM-style evaluation, separate *what is wrong*, *what is fine and why*, and *what is dangerously touchy*. ## Risk A decision (or a decision nobody made) that may prevent a quality attribute scenario from being met. Good form: **decision → consequence → endangered scenario/driver.** > "All services share one relational database (decision), so a single expensive analytical query can exhaust connections and stall checkout (consequence), endangering the 99.95% checkout availability goal (driver)." Bad form: "the database is a concern." A risk without a named consequence and a named endangered goal cannot be prioritised or closed. Risks are *not* automatically defects to fix — leadership may knowingly accept one. What matters is that acceptance becomes conscious. ## Non-risk A decision the review judges acceptable **given stated assumptions**. The assumption is the whole point. > "A 15-minute session cache is acceptable, assuming (a) immediate logout revocation is not a compliance requirement and (b) peak stays under 5k rps." Value: - **It records the expiry condition.** Assumptions age. When compliance later mandates instant revocation, this line is where you learn the design silently became risky. - **It stops re-litigation.** Next review, nobody re-argues it from scratch; they check whether the assumptions still hold. - **It calibrates the report.** A review that lists only problems reads as an attack and invites defensiveness; a review that says "these twelve decisions are sound because X" is far more credible. A non-risk whose assumptions are not written down is worthless — it is just an unsupported "looks fine". ## Sensitivity point A property, parameter, or decision where a small change produces a disproportionate change in **one** quality attribute. Examples: number of replicas ↔ availability; thread-pool/connection-pool size ↔ throughput and tail latency; batch window length ↔ data freshness; whether a module boundary is an interface or a direct call ↔ modifiability. Sensitivity points are where you focus measurement, load testing, alerting and change control. Notably, a sensitivity point need not be a problem — it is a *lever*, and knowing your levers is the practical payoff of a review. ## Trade-off point A decision that is a sensitivity point for **two or more** attributes that move in opposite directions. Classic pairs: | Decision | Helps | Hurts | |---|---|---| | Synchronous cross-region replication | durability, consistency | write latency, availability under partition | | Encrypt-everything + strict authz per call | security | latency, operational complexity | | Aggressive caching | performance | freshness/consistency | | Fine-grained microservices | independent deployability, team autonomy | end-to-end latency, operational cost, debuggability | | Extra abstraction layers | modifiability, testability | performance, cognitive load | A trade-off point must be *decided*, not solved — someone with authority chooses which attribute wins, and the choice belongs in an architecture decision record with its rationale. ## Relationships - Every trade-off point is a sensitivity point; the reverse is not true. - A sensitivity point becomes a risk when the current setting doesn't satisfy a prioritised scenario, or when nobody monitors it. - A non-risk becomes a risk when its assumption is falsified. - Related risks are grouped into **risk themes** ("no failure isolation in the data tier", "no operational visibility") and mapped to business drivers — themes are what leadership funds; individual risks are what engineers fix. ## Traps - Recording risks with no owner, no date and no endangered goal. - Calling every disagreement a trade-off; if only one attribute moves, it's a sensitivity point. - Mistaking a *preference* (language, framework taste) for a risk. - Letting the architect's confidence convert a risk into a non-risk without writing the assumption that justifies it.
- Can a sensitivity point be a good thing?Yes — it is a lever. Knowing that availability moves sharply with replica count tells you exactly what to tune, monitor, alert on and change-control. It only becomes a risk if the current setting misses a prioritised scenario or nobody is watching it.
- How do you keep review findings from dying in a document?Give each risk an owner and a date, roll risks into a few themes tied to business drivers so leadership can fund them, record each trade-off decision as an ADR with rationale, and convert sensitivity points into monitored SLOs or automated fitness functions so regressions are caught continuously.
A building inspection: cracks that endanger the structure (risks), things that are sound given the soil survey (non-risks), the load-bearing wall you must not touch (sensitivity point), and the window size that buys daylight but costs insulation (trade-off point).
saying these in an interview costs you the question
- Using "risk" and "trade-off point" interchangeably
- Recording non-risks without the assumptions that justify them
- Vague risks with no consequence and no endangered goal
- Assuming every risk must be fixed — conscious acceptance is a valid outcome
- Treating personal technology preferences as findings