Architecture is the set of decisions that are expensive to change later. Learn to reason about quality attributes and trade-offs — and to record the decisions you make.
Why: architecture is the set of early, structural decisions that are costly to change once built — how the system is split, how parts communicate, where data lives — as opposed to the everyday code choices that are cheap to revise. When: invest architectural effort where reversing a decision later would be expensive; stay lightweight elsewhere. Where: an architect’s job is to identify those few high-stakes decisions and get them approximately right.
Cheap to change (design, refactorable): a class name, a function's internals,
a local algorithm.
EXPENSIVE to change (architecture): monolith vs. microservices, sync vs. async,
the database paradigm, the trust/security boundaries, the deployment model.
Architecture = the decisions you'd hate to undo in year two.
Spend your judgment there; keep everything else flexible.Why: architecture is shaped by non-functional requirements — the quality attributes like scalability, availability, latency, security, and maintainability — because these, not features, determine the structure. When: gather and prioritize quality attributes up front; a system built for 100 users differs fundamentally from one built for 100 million. Where: you cannot maximize all of them, so architecture is the art of choosing which to optimize.
Features tell you WHAT to build. Quality attributes tell you HOW to structure it:
scalability handle growth in load/data
availability stay up despite failures
latency respond fast enough
security protect data + access
maintainability change safely over time
cost fit the budget
You can't maximize all at once. Rank them for THIS system — that ranking
is what the architecture optimizes.Why: every architectural choice trades one quality for another (microservices buy scalability and independent deploys at the cost of operational complexity), so there is no "best" architecture, only one best-suited to its priorities — and because these decisions are consequential, you record them. When: write an Architecture Decision Record (ADR) for each significant choice: the context, the options, the decision, and the consequences. Where: ADRs give future engineers the reasoning, so decisions can be revisited with the original context intact.
# An ADR (Architecture Decision Record) — one short markdown file per decision:
# docs/adr/0007-use-event-driven-integration.md
# 7. Use event-driven integration between order and billing
Status: Accepted
Context: order and billing scale differently; sync coupling causes cascading
failures under load.
Decision: integrate via an event stream; billing consumes OrderPlaced events.
Consequences: + independent scaling & deploys; - eventual consistency, more ops.
# No "best" architecture — only the best fit for the priorities. ADRs record WHY.