"It depends" is the most honest sentence an architect says, and the least useful thing anyone in the room hears. I have said it in three countries. Every time, the question did not go away. It simply got answered later by somebody with less context and more confidence.
Every architectural decision is a negotiation: between now and later, speed and safety, cost and capability.
- Our job was never to find perfect solutions. The word that separates a senior engineer from an architect is appropriate.
- Everyone says "it depends". Almost nobody finishes the sentence, and finishing it takes five moves.
- The six tensions that get traded on real platforms, and what this discipline quietly builds in you while you practise it.
Appropriate, Not Perfect
As architects, our job is not to find perfect solutions. It is to find appropriate ones, and the entire difference between those two words lives in trade-offs. A perfect solution is one that wins on every dimension at once, which is another way of saying it is one nobody has costed yet. An appropriate solution is one that wins on the dimensions that matter most for this scenario, this team, this year, and knowingly gives ground on the rest.
This is where pragmatism stops being a personality trait and becomes a skill. Cost, resilience, scalability, availability, delivery speed: all of them matter, always, and a list where everything is a priority is a list with no priorities in it. The architect's actual work is naming which one matters most right now, saying so out loud, and having the evidence to survive being asked why. Everything ranked first is nothing ranked first.
Depends on what, though? That is the part we usually leave unsaid, and it is the only part with any value in it. On a search platform I worked on in Japan, the budget was a hundred milliseconds end to end. Once that number is on the table, half the architecture stops being a matter of opinion. A synchronous call to a service that sometimes takes eighty milliseconds is no longer a design choice, it is a budget violation. Caching stops being a nice-to-have and becomes the price of entry. The constraint did not make the decision easy. It made the decision decidable, which is a different and far more useful thing.
"It depends" is a valid answer with the second half missing
Never let it stand alone. Follow it immediately with the two or three things it actually depends on, and what each one would have to be for the answer to flip. "It depends on whether we can tolerate five minutes of stale pricing. If we can, we cache and this gets much cheaper. If we cannot, we pay for a synchronous read and I need another two weeks." That is a decision handed to the room with its conditions attached, and it closes the question instead of deferring it.
Map What Is Actually Being Traded
Most bad architecture arguments are two people optimising different dimensions without either of them saying which. Write the dimensions down and the argument usually resolves itself, because the disagreement was never about the technology. It was about which axis mattered more, and that is a question the business can answer once you ask it properly.
These are the tensions I have watched get traded, again and again, on real platforms in payments and in e-commerce.
Notice that not one of these has a correct answer in the abstract. Each one has a correct answer for a named scenario with numbers attached, and no answer at all without them.
Watch a Decision Change Its Mind
Here is the exercise that convinced me this was worth doing properly, and it takes about ten minutes on a whiteboard. Take one real decision: an order confirmation goes out after checkout, and you can either call the mail service synchronously in the request path or publish a message and let a worker handle it. Score both against the criteria that matter, weight each criterion by how much it matters here, and let the arithmetic speak.
| Criterion | Weight | Synchronous call | Queue and worker |
|---|---|---|---|
| Latency under peak load | ×3 | 2 | 5 |
| Failure isolation | ×3 | 2 | 5 |
| Operational simplicity | ×2 | 5 | 2 |
| Time to first ship | ×2 | 5 | 3 |
| Weighted total | 32 | 40 |
Scores are 1 to 5, high is better. The queue wins on this weighting, and not by a rounding error.
Now change the context without touching a single score. The launch is in three weeks, the first month's volume will be a tenth of the forecast, and the team has never operated a queue. Time to first ship becomes a four, latency under peak drops to a one, because there is no peak yet. Rerun the same arithmetic and the synchronous call wins, 38 to 36.
Nothing about the technology changed. The business context changed, and the right answer moved with it. That is the entire argument of this essay compressed into one table, and it is also the best defence I know against the most exhausting conversation in architecture, the one where two experienced people argue about queues in the abstract for forty minutes. Put the weights on the board and the disagreement relocates to where it belongs: not to the technology, but to what the business is actually optimising for this quarter. That question has an owner, and it is usually not you.
Trade-offs Need Merit, and Merit Needs Evidence
Here is the part that separates a trade-off from a preference: trade-offs are not gut feelings. They need merit. Evidence. Data. Experienced architects develop a good nose, and that nose is genuinely valuable for knowing where to look first. It is not valuable as a substitute for looking. A decision that rests on instinct alone cannot be reviewed, cannot be inherited by whoever holds the system after you, and cannot be defended in the one meeting where it really counts.
This is how I have learned to build fact-driven trade-off analysis into ordinary work, in five moves.
-
1
Frame the problem clearly
Misunderstood problems lead to misguided trade-offs, and no amount of rigour further down rescues a decision aimed at the wrong question. Before anything else, state what is actually being decided, for whom, and under what constraint. If the room cannot agree on that sentence, stop there. You have found the real disagreement.
-
2
Map the dimensions that matter
Name the axes this specific decision is being traded on, from the list above or from the scenario in front of you, and rank them for this case. The ranking is the architecture. Two teams with identical technology and different rankings will build two different systems.
-
3
Quantify when you can
Even rough estimates bring clarity: a QPS target, an RTO and RPO you can actually meet, expected user growth, a latency budget. What you are after is defensibility, and a number you rounded on purpose beats an adjective every time. The toolkit for producing them fast is in Precision Is Not the Point, and what each availability nine really costs you is in Nobody Promised You 100 Percent Uptime.
-
4
Capture the decision in writing
An Architecture Decision Record, or any honest review template, exists so the team understands the why and not only the what. Record the options you rejected and the conditions under which this call should be reopened. A year from now, when the constraint has moved, that record is the difference between revisiting a decision and relitigating it.
-
5
Review from more than one seat
What is ideal for development is rarely ideal for operations, and what is elegant for both may be unaffordable for finance or unacceptable to audit. Get the full view before you commit, not after. This is the discipline the next essay in this series is entirely about.
The trade-off nobody wrote down
An undocumented trade-off does not stay a trade-off. Within a year it has quietly become a constraint that everyone works around and nobody can explain, and the team inherits the cost without ever having seen the reasoning that bought it. When someone new asks why the system works this way and the only available answer is a shrug, you are looking at a decision that was made and then abandoned by the people who made it.
There is a natural partner to this discipline, and it is the one this series opens with. Evidence only protects you if you gathered it honestly, and the criteria have to be written before the options are on the table, not after. Otherwise the analysis quietly bends toward the answer you already liked. That is the subject of Cognitive Bias Is Enemy Number One, and trade-off analysis without it is just preference with a spreadsheet attached.
- Write the criteria on the board before the options go up. Two minutes, in front of everyone. It is the single highest-value habit in this whole essay.
- Put a weight on each one and ask the business owner to challenge the weights, not the technology. That is the conversation you actually need from them, and the only one they are qualified to have.
- Attach one number to the decision. A latency budget, a QPS target, an RTO. Any number at all moves the room from taste to evidence.
- Record what would make you reopen this. One sentence in the decision record. It is what turns a future argument into a scheduled review.
What This Model Strengthens
Practised over years, this discipline does something beyond producing better decisions. It changes what you are like to work with, and those changes are why people start bringing you the hard calls.
Build this muscle and you become calm in the room. The voice of reason in ambiguity. The one people want to consult, not because you know everything, but because your thinking process is trustworthy.
Knowing how to weigh the options is one half. Knowing which one deserves your attention today is the other. Article 4 turns to pragmatism: why "no", "not now", and "let's do it" are three different mindsets, and how right-fit beats perfect every single time.