Architecture Is About Trade-offs, Not Fashion

Every few years the industry agrees on a default answer. Microservices. Serverless. Event sourcing. Monorepos. The defaults are rarely wrong in themselves; the damage comes from adopting them as identity rather than as a decision with costs.

I tend to start with a modular monolith because it preserves optionality while avoiding distributed-system complexity. That is a trade-off, not a doctrine. If a team is genuinely constrained by independent deployment or wildly different scaling profiles, splitting is the right call — and I have made it.

What a real architectural decision contains

• The forces at play: team size, deployment constraints, data ownership, latency, compliance
• At least two options that were seriously considered
• What each option costs, not only what it gives
• What would have to change for us to revisit the decision

That last point is the one most often skipped, and it is the most valuable. An architecture with explicit reversal conditions can be revisited without it feeling like an admission of failure.

Complexity is a budget

Every team has a finite amount of complexity it can carry while remaining productive. Distributed transactions, a service mesh, three data stores, and an event bus can all be justified individually. Together they may consume the entire budget, leaving nothing for the complexity of the actual business domain — which is the only complexity customers pay for.

Spend your complexity budget on the problem, not on the infrastructure around the problem.

Architecture protects organizational velocity

The most important property of an architecture is usually not performance. It is how many people have to agree before a change can ship. Well-drawn module boundaries let teams move without permission. Badly drawn ones turn every feature into a negotiation.

That is why architecture is a leadership concern and not only a technical one. The structure of the software eventually becomes the structure of the working day.