Skip to main content

There Are No Right Answers, Only Tradeoffs

What This Concept Is​

The first law of software architecture, as Neal Ford and Mark Richards state it, is:

Everything in software architecture is a tradeoff.

The corollary: if an architect tells you something is always the right answer, they are either selling something or inexperienced.

A tradeoff-first stance means: every architectural move is evaluated as a pair of answers to the same question - what does this buy? what does this spend? - rather than as a universal best practice. If you cannot name what you are spending, you have not finished thinking.

Why It Matters Here​

This is the stance the rest of the semester depends on. Cluster 2 gave you characteristics; Cluster 3 gave you fitness functions; this cluster gives you the language to trade between characteristics, because you will never satisfy all of them at once.

Engineers raised on "best practices" and "clean code" tend to slide into an absolutist mode:

  • "microservices scale better" (so use them) - ignores operational complexity
  • "eventual consistency doesn't work for payments" (so don't use it) - ignores the domains where it does
  • "caching is an optimization" (so avoid it early) - ignores systems whose architecture is caching

The tradeoff stance replaces absolute claims with conditional ones: "microservices buy independent deployability; they spend operational complexity and consistency simplicity." Now there is a conversation.

Concrete Example​

Three proposed moves on the payments platform. Same platform, three tradeoffs, no universal right answer.

Move 1: Add a read replica for balance queries.

  • Buys: lower latency on balance reads, headroom for traffic spikes.
  • Spends: read-after-write inconsistency for a bounded window; complexity of replica failover; two systems to monitor.
  • Right answer? Depends. For a support dashboard, yes. For the teller's immediate post-transaction balance check, maybe not.

Move 2: Split the teller service into teller-read and teller-write.

  • Buys: independent scaling of read vs write; clearer failure modes.
  • Spends: one more network hop; two deployment targets; coordination during releases.
  • Right answer? Depends. If the read:write ratio is 50:1 and reads dominate cost, yes. If it's 3:1, probably not.

Move 3: Add a message queue between teller client and ledger service.

  • Buys: resilience to ledger slowness; smoother load; clearer retry semantics.
  • Spends: immediate "transaction accepted" response before the ledger has agreed; a whole new failure mode in the queue itself.
  • Right answer? Depends. Is the business okay with eventual confirmation? For a teller, probably not. For a batch import, yes.

Same tool (separation, replication, queueing) gives a different answer each time because the characteristics being optimized differ.

Common Confusion / Misconception​

"There must be a right answer somewhere." Sometimes one option is clearly worse - but that does not make the remaining one "right" without cost. You still paid something.

"If it's a tradeoff, it is arbitrary." Tradeoffs are deeply non-arbitrary. They are grounded in the top-3 characteristics, the business, and the constraints. The absence of a universal answer is not the absence of a principled answer.

"Best practices save us from tradeoffs." Best practices are compressed tradeoffs from someone else's context. They are useful as defaults, dangerous as rules. A best practice unexamined is an imported opinion.

"Experienced architects just know." What they know is a library of tradeoff patterns, not a library of right answers. Their "just know" moves are recognitions of a tradeoff they have seen before.

How To Use It​

Every architecture proposal goes through the buys/spends template:

Move: [the architectural change]

Buys:
- [characteristic 1 it improves, and by how much]
- [characteristic 2 it improves, and by how much]

Spends:
- [characteristic or constraint it worsens, and by how much]
- [operational or organizational cost it introduces]

Top-3 characteristics this move lands on:
- [which of our top-3 this supports or hurts]

Alternatives considered:
- [alternative 1, with its buys/spends]
- [alternative 2, with its buys/spends]

Decision: [chosen move]
Reasoning: [why, in one paragraph, grounded in the top-3]

If any proposal skips "spends" or "alternatives," reject the review and ask for them. A proposal with zero costs is not a proposal; it is a pitch.

Check Yourself​

  1. A colleague proposes "we should always use idempotency keys." Rewrite as a tradeoff.
  2. Give an example where the "right answer" in one system is the wrong answer in another, and name the characteristic that flipped.
  3. Why is "zero downtime" almost never a free property?

Mini Drill or Application​

Pick three recent architecture proposals from your work (or three common patterns: circuit breakers, event sourcing, GraphQL). For each, complete the buys/spends template, including explicit "spends" and at least one alternative. Force yourself to write the costs even if the move is obviously good; that's where the practice lives.

Then hand one to a colleague and ask them to disagree with the decision using only the template. If they can't, the template is too shallow.

Read This Only If Stuck​