Tradeoff Analysis

Overview

Tradeoff analysis is a structured way to answer "what do we give up?" Every architecture improves some qualities at the expense of others. The Architecture Tradeoff Analysis Method (ATAM) from the Software Engineering Institute formalized this by evaluating an architecture against prioritized scenarios and listing risks, sensitivity points, and tradeoff points.

Run the analysis with architects, operators, and product owners in the room. Different roles surface different scenarios, and the disagreements between them usually point to the tradeoffs that matter most.

How it works

Start with ranked scenarios, then examine each option against them.

Scenario              Option A (SQL)     Option B (Dynamo-style)
write 10x spike       risk: single node  ok: partitioned
cross-entity query    ok                 risk: needs index design
regional outage       tradeoff: failover tradeoff: stale reads
                      adds minutes       possible
Sensitivity: partition key choice (B), replica lag (A)

Highlight tradeoff points, where one decision moves two qualities in opposite directions. Decide, write down the accepted downsides, and set a metric or date that would reopen the decision.

Pitfalls

• Using a weighted score as the answer. Totals hide the one scenario that actually matters.
• Evaluating only the happy path. Include failure, growth, and operations scenarios.
• Forgetting non-technical factors such as team skills and hiring.
• Doing it once. Load and priorities shift, so state when to revisit.
• Skipping evidence. Prototype or benchmark the riskiest assumption instead of arguing about it.

Key takeaways

• Evaluate options against ranked, measurable scenarios.
• Name risks, sensitivity points, and tradeoff points explicitly.
• Record accepted downsides along with the decision.
• Define what evidence would make you revisit.