Architecture decisions that age well — and the ones that don't
Every system is the sum of decisions made when no one could fully see the future. Some of those decisions get cheaper over time — they keep paying off long after you forgot you made them. Others compound quietly into debt, and you only feel the interest years later when a “simple” change touches forty files.
The skill isn’t predicting the future. It’s recognising, in the moment, which kind of decision you’re making.
Not every decision carries the same weight
I find it useful to borrow the one-way versus two-way door idea and apply it to architecture. Most choices are reversible — a function, a schema for one feature, a library you can swap. Get those wrong and the cost is small; you should make them fast and move on.
A few are one-way doors: a data model everything depends on, a boundary between services, a core integration, an assumption baked into every layer above it. Those deserve real deliberation, because the cost of changing your mind later is measured in quarters, not afternoons. Most teams get this exactly backwards — agonising over reversible details and rushing the decisions they can’t undo.
What makes a decision age well
The choices I’ve watched stay cheap over the years tend to share a few traits:
- They preserve optionality. They keep doors open rather than committing you to one path before you have to. A decision that lets you change your mind cheaply is worth more than the “optimal” one you can never revisit.
- They have clear boundaries. When a component does one thing behind a clean interface, you can replace its insides without the rest of the system noticing. Good fences are what let you change anything at all.
- They’re boring. Proven, well-understood technology is boring precisely because its failure modes are known. Boring scales; novelty has a way of presenting its bill at the worst moment.
The ones that age badly
The decisions that turn into debt usually do the opposite. They couple things that didn’t need to be coupled, so a change in one place forces changes everywhere. They optimise prematurely for a scale you don’t have yet, paying complexity now for a problem that may never arrive. Or they bet the foundation on something shiny and unproven because it was exciting — and excitement is a poor substitute for knowing how a thing breaks.
The common thread is cleverness for its own sake. Clever code is satisfying to write and miserable to live with, because someone — often you, later — has to hold all of it in their head to change anything safely.
Buy time, not cleverness
The best architectural decisions don’t try to be right forever. They try to keep the cost of being wrong low. They buy you time and options, so that when you understand the problem better — and you always will, later — changing course is a manageable task rather than a rewrite.
You can’t see the future. You can decide in a way that doesn’t punish you for not having seen it. On a platform meant to run for years, that restraint is worth more than any individual clever idea.