Architecture diagrams age fast. The boxes and arrows that felt definitive at kickoff rarely survive first contact with real usage, real scale, or a real change in strategy. That's not a failure of the diagram — it's a reminder that architecture isn't a picture, it's a set of bets about what will need to change and what won't.

Every architecture is a bet on change

Choosing a database, a service boundary, or a deployment model is really choosing which future changes will be cheap and which will be expensive. The teams that get burned aren't the ones who chose "wrong" — they're the ones who never made the bet explicit, so nobody noticed how expensive a seemingly small change had quietly become.

Design for the change you expect, not the scale you hope for

Most systems don't fail from too little architecture; they fail from architecture aimed at the wrong kind of future — built for a scale that never arrived, at the cost of flexibility that was needed on day one. The more useful question isn't "will this scale to a million users," it's "what will we need to change first, and did we make that easy?"

What we optimise for

  • Reversibility of decisions over theoretical elegance.
  • Boundaries that match how the organisation actually communicates, not an idealised org chart.
  • A system a new engineer can hold a mental model of within a week, not a quarter.

The best architecture is rarely the most sophisticated one on paper. It's the one that's still easy to change the day the assumptions underneath it turn out to be wrong.