Trade-off Analysis Framework

Why Structured Trade-off Analysis Matters

Senior engineers are not valued for knowing the "best" technology. They are valued for understanding which trade-offs are acceptable given the current constraints. A structured framework helps remove cognitive bias, creates alignment across teams, and produces documentation that stays useful for years.

The Weighted Scoring Matrix

For significant decisions (database selection, service decomposition, build vs. buy), a weighted scoring matrix keeps things grounded:

1. List criteria. Performance, operational complexity, team familiarity, cost, vendor lock-in, security posture, scalability ceiling, time to implement.
2. Assign weights. Distribute 100 points across criteria based on business priorities. If reliability is critical, weight operational complexity and scalability higher. If time-to-market matters most, weight team familiarity and time to implement.
3. Score each option. Rate each option 1-5 on each criterion. Use evidence, not opinions: run benchmarks for performance, check job market data for hiring, calculate TCO for cost.
4. Calculate weighted scores. Multiply score by weight for each criterion, then sum for each option. The highest total score is your recommended option.
5. Sanity check. If the result surprises you, look at whether your weights actually reflect business priorities.

The Reversibility Matrix

Jeff Bezos popularized the Type 1 / Type 2 decision framework. Here is how it applies to architecture:

The key insight: most decisions are Type 2, but teams treat them as Type 1 and create unnecessary bottlenecks.

Blast Radius Assessment

Before committing to a decision, map the blast radius:

• Scope. How many services, teams, or customers are affected?
• Severity. If this goes wrong, is it a minor inconvenience or a P0 incident?
• Recovery time. How long would it take to roll back or migrate away?
• Data impact. Does this decision affect data at rest? Data migrations are the hardest to reverse.

High blast radius decisions demand more rigorous analysis, broader stakeholder input, and explicit rollback plans.

Practical Example: Choosing a Message Broker

This does not mean Kafka is always the right pick. It means that given these specific weights (reflecting a throughput-sensitive, ops-capable team), Kafka scores highest. A startup with no Kafka expertise would weight "Ops complexity" and "Team familiarity" higher, and that would likely flip the result toward SQS.

When to Revisit a Decision

Schedule a decision review when the team doubles in size, traffic grows 10x, the original author leaves, a major incident traces back to the decision, or 18 months have passed. Write a new ADR documenting whether the original trade-offs still hold.