Trade-off analysis
The first law of software architecture is that everything is a trade-off. That makes trade-off analysis the architect's core skill: comparing options honestly, in the context of this system, and choosing the least worst. Done badly, it's a scorecard where irrelevant criteria outvote the important ones, or weeks of analysis on a decision you could reverse in a day. This module shows how to do it well, and how to know when to stop.
1. The idea
A sound trade-off analysis follows the same few steps every time:
| Step | What you do |
|---|---|
| 1. Options | List the real alternatives, including "do nothing" and "a simpler version". Make sure they don't overlap. |
| 2. Criteria | Take the criteria from this system's context: the top characteristics (Module 04), constraints, and what's likely to change. |
| 3. Compare | For each criterion, which option is better, and by how much? Use scenarios ("what happens when we add a consumer?") rather than opinions. |
| 4. Weigh | Weight each criterion by how much it matters here. Never just count wins. |
| 5. Decide and record | Choose, and write down what you gave up and when to revisit (Module 27). |
Two more tools. Redirection: sometimes the best option is to change the question. Instead of "how do we make this slow query faster?", ask "does it need to run here, now, at all?" And reversibility: a decision you can undo in a day deserves an hour of analysis; one you can't undo for years deserves prototypes and review. Spending weeks on the first kind is analysis paralysis.
2. How it works
The order service must tell three other services about every new order. Option A: publish to one topic that every consumer subscribes to. Option B: send to a separate queue per consumer. Watch the scorecard, then watch the context change the answer.
Redirection: change the question
A monthly sales report runs a 40-second query on the production database, and checkout slows down whenever finance runs it. Watch the obvious fix, then the redirected one.
3. Try it yourself
A weighted trade-off matrix
Pick a decision. Each row says which option wins that criterion. Set how much each criterion matters in your context (0 = not at all, 3 = critical) and watch the totals. Then try the context presets: the same rows give different answers.
4. Trade-offs
Analysis vs speed
More analysis finds more trade-offs but delays everything that depends on the decision. Match the effort to how hard the decision is to reverse, and time-box it.
Generic vs contextual comparisons
Generic comparisons ("Kafka vs RabbitMQ") are a good starting list of criteria, but their verdicts are out of context. Re-weight every criterion for your system.
Qualitative vs quantitative
Ratings ("better", "much worse") are fast and work before anything exists. Numbers from a prototype are slower but settle disputes. Use ratings to shortlist and numbers to decide between the last two.
Decide now vs later
Deciding at the last responsible moment uses the most information. Deciding too late blocks teams who need the answer. Ask who is waiting on the decision, and when.
5. In real projects
Beware the vendor demo and the conference talk. They present the trade-offs that flatter the tool. Ask what it costs to run, to learn and to leave, and look for the context in which a famous company chose it.
Use scenarios to compare. "Add a new consumer", "a consumer is down for an hour", "the message format changes": walking each option through each scenario turns vague preferences into visible differences.
A problem-solving checklist keeps you honest under pressure: what exactly is the problem; what are the constraints; what are at least three options (including doing nothing); what does each trade away; which do we choose; how will we know it worked?
Iterate. Architecture doesn't have to be decided all at once. Make the decisions that are hard to reverse first and carefully, and leave the reversible ones to be made, and remade, as you learn.
Say it in the interview
- "How do you compare two options?" I take the criteria from this system's top characteristics and constraints, compare the options on concrete scenarios, and weight each criterion by how much it matters here. Then I record the choice and what we gave up.
- "Topic or a queue per consumer?" A topic makes adding consumers easy and decouples the producer; separate queues allow different contracts, per-consumer security and monitoring. Which wins depends on whether consumers change often or need different data.
- "How long should a decision take?" As long as it's hard to reverse: an hour for an easy-to-undo choice, prototypes and review for one we'll live with for years.
- "Option A is the best practice."
- Counting pros and cons without weighting them.
- Not mentioning what the chosen option costs.
6. Remember it
How this hook works: what "weigh, don't count" means
What the slogan means, phrase by phrase
- "Weigh"
- Each criterion counts as much as it matters in this context: some count three times, some not at all.
- "don't count"
- Adding up wins treats a pool you'll never use the same as the commute you take every day.
Why this picture fits: the most common trade-off mistake isn't missing a criterion, it's letting irrelevant ones outvote the important ones.
The story → the concept
| Choosing a flat | Choosing an option |
|---|---|
| Twenty features on the website | A generic comparison table |
| You don't drive; you work from home | This system's context |
| Commute and quiet count most | Weights from the top characteristics |
| Renting for a year vs buying | Reversibility decides how long to analyse |
The trap it saves you from
The out-of-context scorecard: a precise-looking table whose verdict doesn't apply to your situation.
7. Common mistakes
8. Design exercise (30 minutes)
- Pick a real decision (5 min). One your team made or is making. List at least three options, including a simpler one.
- Build the matrix (15 min). Write five criteria from your context, mark the winner of each, weight them 0–3, and total. Did the weighting change the answer?
- Try redirection (10 min). Restate the problem in two different ways ("does it need to happen here? now? at all?") and see whether a new option appears.
9. Self-check quiz
What turns a pros-and-cons list into a trade-off analysis?
All consumers are internal, need the same data, and a new one is added every month. Topic or queue per consumer?
What is redirection?
A decision can be reversed in a day. How should you handle it?
Why be careful with a vendor's comparison table?
10. Go deeper
| Resource | Time | Why |
|---|---|---|
| Software Architecture: The Hard Parts (Ford, Richards, Sadalage, Dehghani) | book | A whole book of trade-off analysis for distributed systems, including the topic-vs-queue example. |
| Is Design Dead? (Martin Fowler) | 30 min | Planned vs evolutionary design, and when to decide. |
| ATAM (Software Engineering Institute) | browse | The formal method behind scenario-based trade-off analysis. |