Skip to main content

Tradeoff Vocabulary

Why this chapter matters

Architects need precise language for disagreement. Without shared vocabulary, teams argue through preferences: "cleaner", "modern", "simple", "scalable", "fast". Those words hide the real tradeoff.

Core tradeoff dimensions

DimensionUseful question
reversibilityHow expensive is it to change this later?
couplingWhich teams, modules, services, or release trains become linked?
cohesionDoes the design keep related behavior together?
latencyWhich user-visible step becomes slower or faster?
throughputCan the system handle more users, data, or interactions?
complexityWho pays the mental and operational cost?
blast radiusWhat breaks if this fails?
optionalityDoes this keep future choices open or close them?
governanceWho can change this safely?
costWhich compute, bandwidth, vendor, and maintenance costs grow?

Tradeoff phrases architects should use

Weak phraseStronger phrase
This is cleaner.This reduces local implementation complexity but increases shared package coupling.
This scales better.This handles independent team release pressure at the cost of duplicated runtime assets.
This is faster.This improves first paint by shifting compute to the server and adds hydration risk.
This is simpler.This is simpler for feature teams but adds platform ownership requirements.
This is future-proof.This preserves optionality for route-level rendering changes.

Tradeoff map

Decision conversation pattern

Use this pattern in reviews:

  1. Name the outcome.
  2. Name the constraint.
  3. Name the accepted cost.
  4. Name the mitigation.
  5. Name the review trigger.

Example:

We are choosing cached SSR for this route to improve first content for anonymous users. We accept higher server/cache complexity. We mitigate it with explicit cache keys, RUM monitoring, and a rollback to static fallback if origin latency regresses.

Review checklist

  • Is the tradeoff stated in concrete dimensions?
  • Is the accepted cost explicit?
  • Is the cost assigned to a team or system owner?
  • Is the mitigation credible?
  • Is the review trigger measurable?

Exercises

  1. Rewrite five "best practice" statements as tradeoff statements.
  2. Pick a current architecture decision and name its blast radius.
  3. Place three team decisions on the quadrant chart.

Source lens

Use this vocabulary across ADRs, system-design answers, capstone reviews, and architecture portfolio narratives.