Trade-off Fundamentals
Every architecture is a set of purchases; the skill is naming what was bought, what was sold, and at what exchange rate.
There are no best practices at the architecture level, only trades. A design that has no downside has not been understood yet. The mature statement of a decision has three parts: what improves, what gets worse, and the condition under which the trade stops being worth it.
The recurring axes
- Consistency against latency and availability.
- Redundancy against cost.
- Flexibility against simplicity.
- Time to market against maintainability.
- Security against usability.
- Local team autonomy against global coherence.
Industry example
Uber's move from a monolith to a very large service estate, and its later consolidation into coarser domain-oriented groupings, is one of the more honest public accounts of a trade being re-priced. The original decomposition bought what it was meant to buy: teams shipping independently at high speed during hypergrowth. It also sold something that only became expensive later — with thousands of microservices, the cost of understanding, operating and changing a cross-cutting flow rose sharply, and ownership of end-to-end behaviour became diffuse.
The correction was not "microservices were wrong". It was that the exchange rate changed. At 200 engineers, independent deployment was worth a great deal and operational overhead was small. At several thousand engineers and thousands of services, the overhead compounded and the marginal value of one more service boundary fell.
The transferable lesson: write down the conditions under which a decision should be revisited, because the decision is rarely wrong at the time and frequently wrong later.
How to state a trade-off properly
"We are choosing asynchronous event delivery for order fulfilment. We gain: the checkout path no longer depends on warehouse system availability, and we absorb bursts. We lose: fulfilment status is eventually consistent, typically under 5 seconds, and we must build reconciliation for stuck events. We would revisit this if customers require synchronous confirmation of stock reservation at checkout."
Interview question
"Describe an architectural decision you made that was right at the time and wrong two years later. What signal should have triggered the revisit?"