Common Trade-off Dimensions

Architecture trade-offs cluster around six dimensions. Every decision involves at least two of them. Understanding the dimensions allows you to anticipate the trade-offs before you encounter them — which means your analysis starts from a position of knowledge rather than discovery.

1. Consistency vs. Availability The CAP theorem in practice. A system that guarantees consistency may sacrifice availability during partitions. A system that guarantees availability may serve stale data. Most business stakeholders want both. The architect's job is to explain why they cannot have both and which one matters more for this use case.
2. Simplicity vs. Flexibility A simple architecture handles the current requirements efficiently. A flexible architecture handles future requirements at the cost of current complexity. The architect who designs for every possible future scenario builds a cathedral. The architect who designs only for today builds a tent. The answer is usually: design for today with clearly identified extension points.
3. Speed vs. Quality Shipping faster means shipping with more technical debt. Shipping with higher quality means shipping later. The trade-off is real but not binary — the Technical Debt Ledger makes the trade-off explicit by documenting what was deferred and what it will cost to repay.
4. Build vs. Buy Building gives control and exact-fit but costs development time and ongoing maintenance. Buying gives speed and reduced maintenance but costs vendor lock-in and feature constraints. Every build-vs-buy decision should include total cost of ownership over 36 months, not just the initial implementation.
5. Centralization vs. Distribution Centralized systems are simpler to manage and reason about. Distributed systems are more resilient and scalable. The operational cost of distribution is often underestimated — distributed systems require distributed expertise, distributed monitoring, and distributed debugging.
6. Coupling vs. Autonomy Tightly coupled components are easy to build and hard to change. Loosely coupled components are hard to build and easy to change. The coupling decision determines the system's change velocity — how fast can you modify one component without breaking another.