Ask an architect almost any question worth asking and you’ll get the same answer: it depends. Should we go microservices or stick with the monolith? Should we cache this? Should we use a message queue here? It depends. It depends. It depends.
It’s become a punchline — the consultant’s get-out-of-jail card, the thing you say to look thoughtful while committing to nothing. But it’s also, annoyingly, correct. The problem isn’t the answer. The problem is stopping there.
The honest version of “it depends”
“It depends” is only a cop-out if you don’t finish the sentence. The useful version names what it depends on, and — crucially — what you’ve chosen to optimise for as a result.
“Architecture is about the important stuff. Whatever that is.”
— Ralph Johnson, quoted by Martin Fowler in Who Needs an Architect?
I’ve always loved that line, precisely because it refuses to tell you what’s important. That’s not a dodge; it’s the whole point. The important stuff is different on every system, in every organisation, at every stage of a product’s life. The architect’s job isn’t to know the right answer in the abstract — there isn’t one. It’s to work out what matters here, and then make the trade-offs that follow honestly and deliberately.
Everything is a trade-off
There is no free lunch in software architecture. Every decision buys you something and costs you something else. You don’t get to avoid the cost; you only get to choose it.
- Split into microservices and you buy independent deployability and team autonomy — and you pay for it in network calls, distributed failure modes, and operational overhead.
- Add a cache and you buy latency and reduced load — and you pay in staleness and a brand-new class of “why is it showing the old value” bugs.
- Reach for a managed service and you buy speed and one less thing to run — and you pay in lock-in and a ceiling on how far you can bend it to your will.
None of these is right or wrong. They’re trades. The question is never “is this good?” but “is this the trade I want to make, given what I’m optimising for?”
So what are you optimising for?
This is the bit that actually matters, and it’s the part that most “it depends” conversations skip. Before you can make a sensible call, you have to be honest about which of these you’re prioritising — because you can’t have all of them at once:
- Time to market — get it in front of users this quarter, accept the debt.
- Cost — keep the monthly bill down, even if it means more manual work.
- Latency / throughput — make it fast, even if it’s harder to build.
- Change-friendliness — make the next ten changes cheap, even if this one is expensive.
- Operability — make it boring to run at 3am, even if it’s less elegant on the whiteboard.
- Team cognitive load — make it something this team can actually hold in their heads.
Pick a different one of those and you get a different — and equally defensible — architecture for the same requirements. That’s why two good architects can look at one problem and design two different systems, and both be right. They’re optimising for different things.
The failure mode isn’t choosing wrong. It’s choosing implicitly — drifting into a design because it’s familiar, or fashionable, or what the last place did, without ever naming the thing you were supposedly optimising for. You end up with an architecture optimised for nobody knows quite what.
A non-decision is still a decision
The other trap is thinking you can avoid the trade by not deciding. You can’t. Deferring a choice is itself a choice — usually the choice to keep your options open, which has its own price (complexity now, in exchange for flexibility later). Sometimes that’s exactly right. Sometimes you’re just paying to postpone a decision you could have made cheaply today. Either way, the clock and the cost are running whether you’ve acknowledged them or not.
Finishing the sentence
So yes — it depends. But next time you hear it (or say it), push for the rest:
It depends on what we’re optimising for. Here, that’s ____. Which means we accept ____ as the cost. And we’re making that trade on purpose.
That’s not a cop-out. That’s the job.