Personal notes · May 2026

System Architect Trade-Offs

Architecture is the set of decisions that are hard to change. My work is not drawing boxes — it is choosing which qualities to favor when they conflict, knowing that "everything in software architecture is a trade-off", and that the right answer is always "it depends." I wrote this note to map the decision space I use when those trade-offs matter.

Author: Linh Truong, MA (Harvard), MBA · Source: LinhTruong.com · Email: Linh@Alumni.Harvard.edu

The question behind this note: which architectural trade-offs are we making on purpose — and which ones are we drifting into because no one wrote them down? What follows is how I think through that.

Covers: Styles · quality attributes · evolution · governance Written: May 2026 ✍️ By: Linh Truong

Foundations

What I Actually Decide as an Architect

Design decisions are local and reversible; architecture decisions are global and expensive to undo. I operate at the altitude where structure, quality attributes, and organization meet.

"Architecture is about the important stuff. Whatever that is." — Ralph Johnson. The corollary: my job is deciding what is important enough to be hard to change later.

The higher the decision, the rarer it is and the more it costs to reverse — so it deserves more deliberation and a written record. Architects spend their analysis budget at the top of the pyramid.

Decides

Structure & boundaries

Architecture style, service boundaries, what is one quantum vs many, where the seams are. These shape everything downstream.

Decides

Quality attributes

Which "-ilities" the system optimizes for, and which it deliberately sacrifices. This is the heart of architectural trade-off work.

Decides

Principles & governance

The rules teams follow, how decisions are made and recorded (ADRs), and the fitness functions that keep the system honest over time.

Two failure modes I watch for Ivory tower (decisions divorced from implementation reality, no code, no feedback) and analysis paralysis (deferring every decision waiting for certainty). The remedy for both is the last responsible moment: decide when delaying costs more than deciding, and stay close to the code.

Foundations

Architectural Characteristics — The "-ilities"

These are the non-functional requirements I trade against each other. I can't maximize all of them; choosing the driving characteristics (usually 3–7) is the architecture.

Operational

Runtime behavior

Performance & latency
Scalability & elasticity
Availability & reliability
Recoverability

Structural

Code & change

Modifiability / maintainability
Extensibility
Deployability
Testability

Cross-cutting

Constraints & the world

Security & privacy
Observability
Usability / accessibility
Compliance / regulatory

The radar: every system has a shape

Same six axes, two deliberate shapes. The monolith trades scalability for simplicity and cost; microservices invert that. Neither is "better" — each is right for a different set of driving characteristics.

The iron law of -ilities Characteristics conflict. Performance vs modifiability, security vs usability, scalability vs simplicity, availability vs consistency. Picking more than ~7 driving characteristics means you've picked none — the design can't optimize for a dozen things at once. Rank them; let the rest be satisfied, not maximized.

Foundations

The First Law & the Coupling Budget

If there's a single sentence to anchor an architect's instincts, it's this — and its companion observation about why the question is always harder than it looks.

First Law of Software Architecture

Everything in software architecture is a trade-off. If an architect thinks they've found something that isn't a trade-off, more likely they just haven't identified the trade-off yet.

Second Law of Software Architecture

Why is more important than how. Knowing how a system is built has value; knowing why it was built that way — the trade-offs accepted — is what lets the next architect evolve it safely.

Coupling is the currency of architecture. Every connection between parts buys integration but spends independence. The architect's job is to put coupling where it helps (high cohesion inside a boundary) and remove it where it hurts (low coupling across boundaries).

Static vs dynamic coupling Static coupling = how parts are wired together (dependencies, contracts) — it determines what you must deploy and change together. Dynamic coupling = how parts call each other at runtime (sync chains, shared transactions) — it determines failure propagation and latency. A good architecture minimizes both, but they trade against each other: removing dynamic coupling (async events) often adds static coupling to a broker and to eventual-consistency handling.

Architecture Styles

The Style Spectrum: Monolithic → Distributed

The single biggest structural decision. It runs along one axis — how many independently deployable units (quanta) — and that axis governs almost every quality-attribute trade-off downstream.

The fundamental partitioning choice. Most teams over-shoot to the right too early and pay distributed-systems tax for scale they don't have. The modular monolith is the underrated default.

Architecture Styles

The Styles, One by One

What each style optimizes for, where it breaks, and the constraint that justifies reaching for it.

Monolithic · technical partitioning

Layered (n-tier)

Presentation → business → persistence → database. Each layer depends only on the one below.

+ Familiar, simple, cheap to start; great for small apps & teams.
− "Architecture sinkhole" (calls pass through layers doing nothing); poor scalability & deployability; technical not domain partitioning.

Monolithic · domain partitioning

Modular Monolith

One deployable, but partitioned internally by business domain with enforced module boundaries.

+ Simplicity & ACID of a monolith + clean seams that make a later split cheap. The pragmatic default.
− Still one deployment/scaling unit; module boundaries erode without discipline (fitness functions help).

Monolithic · extensibility

Microkernel (plugin)

Minimal core + plugins that add features. IDEs, browsers, ETL tools, insurance rules engines.

+ Superb extensibility; features evolve independently of core.
− Plugin contract/registry is critical; not inherently scalable; core can become a bottleneck.

Distributed · decoupling

Event-Driven

Components react to events asynchronously via brokers; broker or mediator topology.

+ Best-in-class scalability, responsiveness, fault tolerance, extensibility.
− Hardest to test & reason about; eventual consistency; error handling & ordering are non-trivial.

Distributed · reuse via services

Service-Oriented (SOA)

Coarse-grained services sharing an enterprise bus; heavy orchestration. Largely superseded.

+ Enterprise reuse & integration across heterogeneous systems.
− ESB becomes a coupling point & bottleneck; shared data; low agility. Mostly a cautionary tale.

Distributed · extreme scale

Space-Based

Remove the central database from the request path; in-memory data grid + async replication. For unpredictable, spiky high volume.

+ Elastic, extreme scalability & performance (the DB stops being the bottleneck).
− Very complex; eventual consistency; hard to test; niche.

Distributed · independence

Microservices

Small, independently deployable services, each owning its data, aligned to bounded contexts.

+ Independent deploy & scale, fault isolation, team autonomy, tech heterogeneity.
− Highest operational complexity; distributed transactions (sagas); needs strong DevOps/observability maturity.

Distributed · no servers to manage

Serverless / FaaS

Functions triggered by events; provider manages infra; pay-per-use, scale-to-zero.

+ No infra ops, elastic, cost-efficient for spiky/low-baseline loads.
− Cold starts, vendor lock-in, execution limits, hard local testing, cost surprises at steady high volume.

Architecture Styles

Style Scorecard

A comparative rating of each style against the characteristics architects care about most (★ = relative strength, 1–5). Use it to shortlist, then validate against your specific drivers — these are tendencies, not guarantees.

Style	Simplicity	Deployability	Scalability	Fault tolerance	Performance	Modifiability	Cost
Layered monolith	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★
Modular monolith	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★
Microkernel	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★
Event-driven	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★
Service-oriented (SOA)	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★
Space-based	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★
Microservices	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★
Serverless / FaaS	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★	★★★★★

How to read this No row is all five-star — that's the point. High scalability/deployability rows (microservices, event-driven) pay in simplicity and cost. The high-simplicity row (layered) pays in scale. Match the strong columns to your top 3 driving characteristics and ignore the rest.

Quality-Attribute Trade-Offs

The -ility Tension Map

The recurring conflicts. Improving the attribute on one side typically degrades the other; the architect's job is to find the point on the line the business actually needs.

Attribute A	tension	Attribute B	Why they fight · how to balance
Performance	⇄	Modifiability	Optimized/coupled code is fast but rigid; clean abstractions add indirection. Optimize hot paths only; keep the rest clean.
Scalability	⇄	Consistency	Scaling out forces CAP choices & eventual consistency. Reserve strong consistency for the data that truly needs it.
Security	⇄	Usability	Every auth step, scan, and confirmation adds friction. Risk-tier the flows; heavy controls only on high-value actions.
Availability	⇄	Cost	Each "nine" ≈ 10× cost (redundancy, multi-region). Set SLOs to business value, not vanity.
Flexibility / configurability	⇄	Simplicity	Every option is a code path to test & a way to misconfigure. Add knobs only when a real need appears (YAGNI).
Time-to-market	⇄	Quality / robustness	Shipping fast accrues tech debt; gold-plating misses the window. Make the debt deliberate and tracked.
Reusability	⇄	Independence / decoupling	Shared libraries/services reduce duplication but create coupling & coordination. Prefer duplication over the wrong abstraction.
Abstraction / portability	⇄	Performance & leverage	Hiding the platform aids portability but forfeits native features & speed. Abstract only where you'll actually switch.

The classic trap Trying to be highly secure and frictionless, highly scalable and strongly consistent, highly flexible and simple — all at once. The result is a system that's mediocre at everything and excels at nothing. Pick a side per tension, write down why, and design boldly toward it.

Quality-Attribute Trade-Offs

Evaluating Trade-Offs: ATAM & Trade-off Points

A structured way to surface and decide quality-attribute trade-offs before they become production incidents. ATAM (Architecture Trade-off Analysis Method) turns vague "-ility" debates into concrete scenarios.

Collect quality-attribute scenarios. Make each one concrete & measurable: "Under 10× normal load, p99 checkout latency stays < 500 ms" beats "the system should be fast."
Prioritize the scenarios. Rank by business importance × architectural risk. You can't satisfy all; find the vital few.
Map scenarios to architectural decisions. For each decision, identify which scenarios it helps and which it hurts.
Find sensitivity points. Decisions where a small change strongly affects one attribute (e.g. the cache TTL strongly affects freshness).
Find trade-off points. The critical ones: a decision that is a sensitivity point for two or more competing attributes (e.g. replication factor improves availability but hurts write latency). These are where the architect earns their keep.
Decide, document, and define the revisit trigger. Record the chosen point on each trade-off and the signal that should make you reconsider.

A single decision that pulls two competing attributes in opposite directions is a trade-off point. These deserve explicit, documented choices — not defaults inherited from a tutorial.

Cross-Cutting Decisions

Coupling, Cohesion & Connascence

The vocabulary that lets you reason precisely about boundaries. "Loosely coupled, highly cohesive" is the slogan; connascence is the measuring stick.

Good modules group what changes together (cohesion) and depend minimally on each other (coupling). Bounded contexts from Domain-Driven Design are the practical tool for finding these lines.

Connascence — a precise coupling scale (weakest → strongest)

Type	Two parts must agree on…	Strength
Name	The name of a thing	Weak (fine)
Type	The type of a thing	Weak
Meaning	The meaning of a value (e.g. `0 = active`)	Medium
Position	The order of arguments	Medium
Algorithm	A shared algorithm (e.g. both ends hash the same way)	Strong
Timing / Execution order	When/what order things run	Strong (avoid)

Rule of thumb Prefer weaker connascence, and keep strong connascence local (inside one module) where it's cheap to change. Strong connascence that crosses a service boundary is exactly the coupling that makes "independent" services impossible to deploy independently.

Cross-Cutting Decisions

Service Granularity — How Small Is Too Small?

"Micro" is not a size target. Granularity is itself a trade-off between forces that push services apart and forces that pull them together.

Disintegrators vs Integratorssplit ⇄ merge

Forces to split (disintegrators)

Distinct, separable business functions
Different scalability / throughput needs
Different fault-tolerance requirements
Independent deployment cadence / team ownership
Different security or data-access profiles

Forces to keep together (integrators)

Frequent chatty calls between them (latency)
A shared transaction / strong consistency need
Shared, hard-to-split data
Tight workflow coupling / one fails ⇒ all fail
Coordination cost exceeds independence benefit

Rule: Split only when a disintegrator outweighs every integrator. When two services must always be deployed and must transact together, they're one service wearing a network cable. Start coarse; split under proven pressure.

Nano-services smell If a "service" can't do anything useful without synchronously calling three others, you've created distributed spaghetti. The network round-trips and failure modes now cost more than the in-process call you replaced. Merge them back.

Cross-Cutting Decisions

Distributed Data Ownership

The hardest part of distributed architecture isn't the services — it's the data. Breaking the shared database is what makes microservices both powerful and painful.

Database-per-service

Each service owns its data

The microservices ideal — true independence, no shared schema coupling.

Costs: no cross-service joins; no distributed ACID transaction → sagas + eventual consistency; data duplication; reporting needs a separate aggregation path (CDC → warehouse).

Shared database

Multiple services, one database

Simple, transactional, easy reporting — and a common starting point.

Costs: schema becomes a coupling point; a change ripples across services; you can't deploy or scale them independently. This is how a distributed monolith is born.

The reporting dilemma Once data is split per service, "give me a report joining orders, customers, and inventory" has no home. Solutions all trade off: data replication / CDC into a read store (eventual consistency), a reporting service that aggregates via APIs (coupling + latency), or a data lake / warehouse fed by events (operational complexity). Decide the analytics story when you split, not after.

Cross-Cutting Decisions

Build vs Buy vs Open Source

One of the highest-leverage architectural decisions — and the one most often made by inertia. The question is whether the capability is a differentiator or a commodity.

	Build	Buy (SaaS / commercial)	Open source
Best when	Core differentiator; unique needs	Commodity; time-to-market critical	Commodity + need control/customization
Upfront cost	High (eng time)	Low	Medium (integration)
Ongoing cost	Maintenance forever	Subscription scales with use	Self-support / ops
Control & fit	Total	Vendor roadmap	High (you have the source)
Lock-in risk	None	High	Low–medium
Key risk	Opportunity cost; reinventing	Vendor lock-in, price hikes, EOL	Support, security patching, license terms

The heuristic Build your differentiators; buy/adopt your commodities. Don't build an auth system, an email service, or a queue to save a subscription — that engineering time is better spent on what makes your product unique. Do build the thing your competitors can't copy. And always assess the total cost of ownership, not the sticker price.

Evolution & Organization

Evolutionary Architecture & Fitness Functions

Requirements change; the "right" architecture today is wrong in two years. Rather than predict the future, build for guided change — and protect the qualities you care about with automated checks.

Build for change

Last responsible moment

Defer hard-to-reverse decisions until delaying costs more than deciding. Keep options open with clean seams; don't pre-build for speculative futures (YAGNI). The modular monolith is the canonical "easy to evolve" baseline.

Guard the qualities

Architectural fitness functions

Automated tests for architectural characteristics: a dependency rule (no UI→DB direct), a latency budget in CI, a coupling threshold, a security scan. They turn "-ilities" from aspirations into enforced, regression-proof constraints.

The Strangler Fig: evolving without a rewrite

Incrementally route functionality from the old system to the new behind a façade, until the legacy is "strangled." Trades the speed of a big-bang rewrite for dramatically lower risk — usually the right trade for systems already in production.

Evolution & Organization

Technical Debt as a Deliberate Trade-Off

Debt isn't inherently bad — it's leverage. The failure is taking it unknowingly and never paying it down. Architects make debt visible and intentional.

Prudent + deliberate

"Ship now, refactor next quarter — the market window is worth it." Good debt.

Prudent + inadvertent

"Now we know how we should have done it." Learning; refactor as you go.

Reckless + deliberate

"No time for design." Occasionally justified, but name the cost.

Reckless + inadvertent

"What's layering?" The dangerous quadrant — debt you don't even know you have.

Managing it Keep a visible debt register; attach an interest rate (how much it slows you per sprint) to each item; budget a fixed slice of capacity to repayment; and use fitness functions to stop new debt of the kinds you've decided to forbid. Unmanaged debt compounds until velocity hits zero — that's the architect's slow-motion failure.

Evolution & Organization

Conway's Law & Team Topologies

Architecture and org chart are the same diagram. If they fight, the org chart wins. I shape teams as deliberately as I shape services.

"Organizations design systems that mirror their own communication structure." — Melvin Conway. So if you want a modular system, build modular teams — the Inverse Conway Maneuver.

Stream-aligned

Owns a value stream

The default team. End-to-end ownership of a slice of product. Most teams should be this.

Platform

Paves the road

Internal products (CI/CD, infra, libs) that reduce cognitive load for stream-aligned teams.

Enabling

Coaches & uplifts

Helps other teams adopt new skills/tech, then steps away. Temporary by design.

Complicated-subsystem

Deep expertise

Owns a part needing specialist knowledge (e.g. a pricing or video codec engine).

Cognitive load is the constraint A team's effective boundary is the size of the system it can hold in its head. Services larger than that produce burnout and bugs; services much smaller produce coordination overhead. Size services to fit a team's cognitive load — that, not a "micro" line count, is the right granularity signal.

Decision Toolkit

Master Trade-Off Matrix

My quick reference for architectural decisions. For each choice: when to lean each way, and the price of the lean.

Decision	Lean A when…	Lean B when…	The cost you pay
Monolith vs distributed	Small team, evolving domain, simplicity wins	Independent scale/deploy, clear bounded contexts	Scaling ceiling, or distributed-ops tax
Technical vs domain partitioning	Tiny app, layer reuse	Aligning to teams & business change	Cross-cutting changes, or some duplication
Sync vs async (orchestration vs choreography)	Simple, traceable flow needed	Decoupling, resilience, fan-out	Coupling/latency, or eventual consistency & debuggability
Shared vs database-per-service	Transactions & reporting matter, few teams	True service independence	Schema coupling, or sagas + no joins
Coarse vs fine granularity	Strong consistency / chatty interactions	Different scale, fault, deploy needs	Larger blast radius, or network overhead
Build vs buy	Core differentiator, unique needs	Commodity, speed to market	Maintenance forever, or lock-in & fit
Performance vs modifiability	Latency is the product	Change velocity is the product	Rigid code, or indirection overhead
Flexibility vs simplicity	Genuinely varied, known futures	Single clear use case (most cases)	Config sprawl & bugs, or a later refactor
Now (debt) vs robust	Market window / learning is dominant	Cost of failure is high (safety, money)	Future interest payments, or a missed window

Decision Toolkit

Decision Framework I Use

How I drive an architectural decision to a defensible conclusion — and leave a trail the next person can follow.

Identify the driving characteristics. Translate business goals into the top 3–7 quality attributes (with measurable scenarios). Everything flows from this ranking.
Find the bounded contexts. Use the domain to find natural seams (DDD). Boundaries decided here are the most expensive to move later.
Shortlist 2–3 styles. Use the scorecard: which styles' strengths align with your driving characteristics? Always include the simplest viable option as a baseline.
Surface the trade-off points. For each candidate, run the lightweight ATAM: which decisions pull competing attributes apart? Decide each consciously.
Check it against the org. Does the team structure support this architecture (Conway)? If not, change the design or the teams — don't pretend.
Choose the simplest sufficient design. The least complex architecture that satisfies the driving characteristics. Complexity must be paid for by a requirement.
Write the ADR & the fitness functions. Record context, options, decision, consequences, and revisit trigger — then encode the constraints you care about as automated checks.

The question I keep asking I replace "what's the best architecture?" with three better questions: "What are the driving characteristics? What trade-offs does each option force? Which trade-offs can this business live with?" The answer is always "it depends" — my job is to make the dependencies explicit.

Decision Toolkit

Architectural Anti-Patterns

The recurring ways architects spend a budget no one asked them to spend.

Big ball of mud

No structure at all

Everything coupled to everything. The absence of architecture; the end-state of unmanaged debt.

Distributed monolith

Split without decoupling

Services that deploy together and share data — all the network cost, none of the independence.

Architecture by implication

No explicit drivers

Nobody defined the characteristics, so the architecture "just happened." Trade-offs made by accident.

Resume-driven design

Tech for the CV

Choosing the trendy stack over the fitting one. Complexity with no requirement to justify it.

Ivory tower

Architects who don't code

Diagrams divorced from implementation reality. Decisions that can't survive contact with the codebase.

Vendor lock-in by default

Accidental dependence

Coupling to a vendor's proprietary features without ever deciding the lock-in was worth it.

Gold plating / over-engineering

Solving non-problems

Building flexibility, abstraction, and scale for futures that never arrive. The cost of YAGNI ignored.

Premature distribution

Microservices too early

Paying distributed-systems tax before product-market fit, when a monolith would ship 3× faster.

Frozen architecture

No evolution path

Decisions treated as permanent; no fitness functions, no revisit triggers. Right for 2019, wrong for now.

Decision Toolkit

Pre-Flight Checklist

I run this before committing to an architecture. A blank line is a trade-off I haven't made consciously yet.

Characteristics & structure

Top 3–7 driving characteristics ranked, with measurable scenarios
Bounded contexts identified from the domain, not the layers
Architecture style chosen against the scorecard, simplest-sufficient
Coupling minimized across boundaries; cohesion high within
Service granularity justified by disintegrators > integrators

Trade-offs made explicit

Every trade-off point surfaced (ATAM) and decided on purpose
Consistency vs availability decided per data type
Build/buy/OSS assessed on TCO, not sticker price
Technical debt deliberate, registered, and budgeted
No characteristic over-optimized at another's silent expense

Organization & data

Team topology supports the architecture (Conway checked)
Each service sized to a team's cognitive load
Data ownership defined; reporting/analytics path decided
Distributed transactions handled (sagas) where data is split
Cross-service contracts versioned and governed

Evolution & governance

Fitness functions encode the characteristics you must protect
Migration/evolution path exists (strangler, not big-bang)
ADRs written with options & consequences, not just the decision
Revisit triggers defined for each major choice
Observability designed in, not bolted on

The one sentence I leave with A great architecture isn't the one with the most capabilities — it's the one whose trade-offs are deliberately chosen to fit this system's driving characteristics, made visible to everyone, and built to be revisited when those characteristics change.

Sources

References & Sources

Annotated bibliography behind this system architecture trade-offs note — quality attributes, styles, coupling, data ownership, evolution, organization, and decision governance. Section tags (e.g. §03) show where each source informed the prose, tables, and diagrams. Radar charts, scorecards, tension maps, and synthesis matrices are my own unless noted.

Scope. Synthesis of software-architecture textbooks, SEI/CMU methods, industry patterns, and practitioner writing (May 2026). Style scorecard ★ ratings are relative tendencies for shortlisting — not benchmark results. Validate every architectural choice against your own driving characteristics, constraints, and load tests before committing to a one-way door.

Citations are numbered continuously [1]–[n] within this section.

Architect role, ADRs & governance (§01, §17, §19)

Johnson, R., "Who Needs an Architect?" IEEE Software, 2003. "Architecture is about the important stuff" — §01 Ralph Johnson quote and altitude pyramid. — §01.
Richards, M., & Ford, N., Fundamentals of Software Architecture. O'Reilly, 2020. Architect decisions vs design decisions; driving characteristics — §01 role cards and §02 -ilities. — §01, §02, §17.
Fowler, M., "Who Needs an Architect?" (bliki commentary). Ivory-tower anti-pattern context — §01 failure modes and §18 ivory-tower row. martinfowler.com — §01, §18.
Nygard, M., "Documenting Architecture Decisions." Cognitect, 2011. ADR format — §01 governance card, §17 step 7, §19 checklist. cognitect.com — §01, §17, §19.
Thomson, J., "Architecture Decision Records." adr.github.io — §17 ADR step and §19 operability checklist. — §17, §19.
Poppendieck, M., & Poppendieck, T., Lean Software Development. Addison-Wesley, 2003. Last responsible moment — §01 failure-modes remedy and §13 evolution card. — §01, §13.

Quality attributes & the -ility tension map (§02, §07)

Bass, L., Clements, P., & Kazman, R., Software Architecture in Practice (4th ed.). Addison-Wesley, 2021. Quality attribute taxonomy and scenario-based design — §02 -ilities grid and §07 tension map. — §02, §07, §08.
Rozanski, N., & Woods, E., Software Systems Architecture (2nd ed.). Addison-Wesley, 2011. Viewpoints and quality-attribute trade-offs — §02 iron-law callout. — §02, §07.
ISO/IEC/IEEE 42010:2022 — Architecture description. Stakeholders, concerns, views — background for §02 driving-characteristics framing. — §02.
Google SRE Team, Site Reliability Engineering — SLOs & error budgets. O'Reilly, 2016. Availability vs cost tension — §07 availability/cost row. sre.google — §07, §19.
Truong, L. (synthesis). Quality-attribute radar (monolith vs microservices) — §02 radar figure. LinhTruong.com — §02, §06.

First & second laws; coupling budget (§03, §09, §16)

Richards & Ford, Fundamentals of Software Architecture. First Law ("everything is a trade-off") and Second Law ("why over how") — §03 law cards and hero lede. — §03, hero.
Parnas, D. L., "On the Criteria To Be Used in Decomposing Systems into Modules." Communications of the ACM, 1972. Information hiding and coupling — §03 coupling currency paragraph. DOI: 10.1145/361598.361623 — §03, §09.
Constantine, L. L., & Yourdon, E., Structured Design. Prentice-Hall, 1979. Coupling and cohesion — §09 boundary quadrant. — §09.
Cummins, J., "Connascence." Connascence.io / software design literature. Connascence scale — §09 connascence table. connascence.io — §09.
Richardson, C., "Pattern: Messaging." microservices.io. Static vs dynamic coupling — §03 static/dynamic coupling callout. microservices.io — §03, §11, §16.

Architecture styles & style scorecard (§04, §05, §06, §18)

Shaw, M., & Garlan, D., Software Architecture: Perspectives on an Emerging Discipline. Prentice-Hall, 1996. Style taxonomy — background for §04–§05 style spectrum. — §04, §05.
Richards & Ford, Fundamentals of Software Architecture. Layered, microkernel, event-driven, microservices, space-based styles — §05 style cards and §06 scorecard rows. — §05, §06.
Newman, S., "Monolith First." martinfowler.com, 2015. Start left on the spectrum — §04 figcaption and §04 earn-every-step-right guidance. martinfowler.com — §04, §05, §18.
Evans, E., Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2003. Domain-partitioned modular monolith — §05 modular monolith and §09 bounded contexts. — §05, §09, §17.
Newman, S., Building Microservices (2nd ed.). O'Reilly, 2021. Microservices trade-offs — §05 microservices card and §06 scorecard. — §05, §06, §10, §18.
Richardson, C., Microservices Patterns. Manning, 2018. Event-driven, space-based, service decomposition — §05 event-driven/space-based styles. — §05, §11.
Jonas Bonér et al., Reactive Manifesto. 2013. Event-driven/responsive systems — §05 event-driven style context. reactivemanifesto.org — §05.

ATAM, trade-off points & sensitivity analysis (§08, §17, §19)

Kazman, R., et al., "The Architecture Tradeoff Analysis Method (ATAM)." CMU/SEI, 2000. ATAM steps — §08 entire section. sei.cmu.edu — §08, §17, §19.
Bass, Clements & Kazman, Software Architecture in Practice. Quality attribute scenarios, sensitivity/trade-off points — §08 trade-off-point diagram. — §08, §17.
SEI Architecture-Centric Engineering. Scenario-based evaluation methods — §08 scenario prioritization. sei.cmu.edu — §08.

Service granularity & microservices decomposition (§10, §15, §18)

Newman, S., Building Microservices. Disintegrators and integrators — §10 granularity trade-off block. — §10, §17.
Richardson, C., "Pattern: Service decomposition." Decompose by business capability / subdomain — §10 disintegrators list. microservices.io — §10, §17.
Skelton, M., & Pais, M., Team Topologies. IT Revolution, 2019. Cognitive load as team-size constraint — §15 cognitive-load callout and §10 sizing guidance. — §10, §15, §19.
Fowler, M., "Microservices." martinfowler.com, 2014. Distributed monolith warning — §09 distributed-monolith quadrant and §18 anti-pattern. martinfowler.com — §09, §18.
Brooks, F. P., The Mythical Man-Month. Communication overhead with team size — background for §15 Conway section. — §15.

Distributed data, CAP & sagas (§07, §11, §16, §19)

Kleppmann, M., Designing Data-Intensive Applications. O'Reilly, 2017. Database-per-service, replication, CDC, sagas — §11 data ownership and §19 distributed-transactions checklist. — §11, §16, §19.
Brewer, E., "CAP Twelve Years Later." IEEE Computer, 2012. Scalability vs consistency — §07 scalability/consistency row. — §07, §11, §16.
Richardson, C., "Pattern: Saga." microservices.io. Distributed transactions without 2PC — §11 database-per-service costs and §19 sagas bullet. microservices.io — §11, §19.
Richardson, C., "Pattern: Database per service." microservices.io — §11 ideal and §16 shared-vs-db-per-service row. microservices.io — §11, §16.
Dehghani, Z., "How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh." martinfowler.com, 2019. Analytics/reporting across services — §11 reporting-dilemma callout. martinfowler.com — §11.

Build vs buy vs open source (§12, §16, §19)

Beck, K., Extreme Programming Explained — YAGNI. Build only what you need — §07 flexibility/simplicity row and §17 simplest-sufficient step. — §07, §12, §17.
McCarthy, J., "Build vs Buy: A Decision Framework." Industry TCO practice — §12 build/buy/OSS table and TCO callout. Synthesized in §12. — §12, §16.
ThoughtWorks Technology Radar. Adopt/hold/assess for OSS components — background for §12 OSS column risks. thoughtworks.com/radar — §12.
Campbell-Kelly, M., & industry SaaS economics literature. Commodity vs differentiator heuristic — §12 build-your-differentiators tip. — §12, §16.

Evolutionary architecture, strangler fig & fitness functions (§13, §19)

Ford, N., Parsons, R., & Kua, P., Building Evolutionary Architectures (2nd ed.). O'Reilly, 2022. Fitness functions and guided change — §13 fitness-functions card and §19 checklist. — §13, §19.
Fowler, M., "Strangler Fig Application." martinfowler.com, 2004. Incremental migration pattern — §13 strangler fig diagram. martinfowler.com — §13, §19.
Feathers, M., Working Effectively with Legacy Code. Prentice-Hall, 2004. Seams for safe evolution — §13 modular-monolith baseline. — §13.
ArchUnit / Structure101 / dependency-cruiser documentation. Automated architecture rules as fitness functions — §13 enforced-constraints examples. archunit.org — §13, §19.

Technical debt as deliberate trade-off (§14, §16, §19)

Cunningham, W., "The WyCash Portfolio Management System." OOPSLA experience report, 1992. Technical debt metaphor origin — §14 opening sub. — §14.
Kruchten, P., "Technical Debt: From Metaphor to Theory and Practice." IEEE Software, 2012. Prudent/reckless debt quadrants — §14 four-quadrant grid. — §14, §16.
Allman, E., "Managing Technical Debt." Communications of the ACM, 2012. Interest rate and repayment — §14 managing-it callout. — §14, §19.
Sculley, D., et al., "Hidden Technical Debt in Machine Learning Systems." NeurIPS, 2015. Debt register discipline — analogy for §14 visibility theme. — §14.

Conway's Law & Team Topologies (§15, §17, §19)

Conway, M. E., "How Do Committees Invent?" Datamation, 1968. Conway's Law — §15 lead-rule quote. — §15, §17.
Skelton, M., & Pais, M., Team Topologies. Stream-aligned, platform, enabling, complicated-subsystem teams — §15 team-type cards. — §15, §19.
Skelton & Pais, "Inverse Conway Maneuver." Shape teams to desired architecture — §15 Inverse Conway Maneuver callout. — §15, §17.
Amazon "two-pizza teams" / organizational design literature (synthesized). Team size and service ownership — §15 cognitive-load theme. — §15, §10.

Decision framework, anti-patterns & author synthesis (§16, §17, §18, §19)

Richards & Ford, Fundamentals of Software Architecture. Seven-step decision framework — §17 steps (driving characteristics, bounded contexts, ATAM, Conway, ADRs). — §17, §19.
Evans, Domain-Driven Design. Bounded contexts — §17 step 2. — §09, §17.
Brooks, The Mythical Man-Month — "plan to throw one away." Big-bang rewrite warning — §13 strangler vs rewrite and §18 premature-distribution themes. — §13, §18.
Fowler, M., "Big Ball of Mud." IEEE Software / bliki. No-structure anti-pattern — §18 big-ball-of-mud card. martinfowler.com — §09, §18.
Richardson, "Antipattern: Shared database." microservices.io — §18 distributed-monolith card. — §09, §11, §18.
Truong, L., System Architect Trade-Offs — personal working notes. May 2026. Altitude pyramid, style spectrum, quality radar, connascence quadrant, ATAM trade-off diagram, strangler fig SVG, master trade-off matrix, style scorecard, pre-flight checklist, synthesis prose. LinhTruong.com — all sections.

Before you cite externally. Architecture "best practices" depend on team size, domain maturity, and operational maturity — a modular monolith beats premature microservices for most early-stage systems (Newman, Fowler). ATAM and scorecard ratings here are teaching aids, not certification requirements. Conway's Law cuts both ways: reorganizing teams is a high-cost lever. Technical-debt quadrants (Kruchten) describe intent, not accounting. Always load-test and run a lightweight ATAM on your top scenarios before production commitments.