Fundamentals of Software Architecture

Contents

• Part 01 · Foundations
  01Introduction
  02Architectural Thinking
  03Modularity
  04Architecture Characteristics Defined
  05Identifying Architectural Characteristics
  06Measuring and Governing Architecture Characteristics
  07Scope of Architecture Characteristics
  08Component-Based Thinking
• Part 02 · Architecture Styles
  09Foundations (of Architecture Styles)
  10Layered Architecture Style
  11Pipeline Architecture Style
  12Microkernel Architecture Style
  13Service-Based Architecture Style
  14Event-Driven Architecture Style
  15Space-Based Architecture Style
  16Orchestration-Driven Service-Oriented Architecture
  17Microservices Architecture
  18Choosing the Appropriate Architecture Style
  19Architecture Decisions
• Part 03 · Techniques and Soft Skills
  20Analyzing Architecture Risk
  21Diagramming and Presenting Architecture
  22Making Teams Effective
  23Negotiation and Leadership Skills
  24Developing a Career Path

Introduction

Software architecture resists single definitions; the authors describe it as the union of structure, characteristics, decisions, and design principles. The chapter introduces the eight expectations of an architect and the two laws that recur throughout the book.

The Four Dimensions of Architecture

Architecture is the intersection of four things: structure (the style — microservices, layered), architecture characteristics (the "-ilities" the system must support), architecture decisions (the rules that constrain construction), and design principles (the guidelines that steer implementation). None of them alone is the architecture.

The Eight Expectations

Every architect must make decisions, continually analyze the architecture, keep current with trends, ensure compliance, possess diverse exposure and experience, understand the business domain, demonstrate interpersonal skills, and navigate organizational politics. The list mixes hard skills with soft skills deliberately.

First Law of Software Architecture

"Everything in software architecture is a trade-off." The corollary: if an architect thinks they've discovered something that isn't a trade-off, they just haven't identified it yet. This frames every chapter that follows.

Second Law of Software Architecture

"Why is more important than how." Implementation details can be looked up; the reasoning behind a decision cannot be reconstructed from the code. Justification is the architect's primary deliverable.

Architecture vs Engineering Practices

Architecture cannot be separated from engineering practices like CI/CD, automated testing, and DevOps. Modern styles like microservices only became viable because containerization and deployment automation made them so. The two evolve together.

Architecture Characteristic

A non-domain consideration the system must support (an "-ility").

Architecture Decision

A constraint that defines what is and isn't allowed in the architecture.

Design Principle

A flexible guideline steering implementation choices.

Architecture Style

The overall topology of the system (layered, microservices, event-driven).

First Law

Everything is a trade-off.

Second Law

Why beats how.

Domain Knowledge

Familiarity with the business problem space, considered essential for architects.

Multiple choice

According to the First Law of Software Architecture, what should an architect conclude if they believe they have found a decision with no trade-offs?

• AThe decision is a best practice and should be adopted broadly.
• BThe trade-off exists but has not yet been identified.
• CThe decision is correct because architecture is sometimes obvious.
• DThe decision should be documented as a design principle rather than as a trade-off.

Multiple choice

Which of the following is not one of the four dimensions the authors use to describe software architecture?

• AStructure
• BArchitecture characteristics
• CImplementation language
• DArchitecture decisions

True / False

The Second Law of Software Architecture says "how" is more important than "why" because implementation correctness is what ultimately ships.

• TrueTrue
• FalseFalse

Spot the issue

A new architect documents only the decisions they made ("Use Kafka for event transport, partition by tenant ID") with no surrounding rationale. Six months later the team debates whether to switch to RabbitMQ. What's the main risk?

• AKafka may not actually support partitioning by tenant ID in all clusters.
• BWithout the "why," the team will relitigate the decision repeatedly and may overturn it for the wrong reasons.
• CThe documentation should have been in Confluence rather than the repo.
• DRabbitMQ is a strictly inferior choice so the debate is unwarranted.

Architectural Thinking

Architects and developers think differently; architects trade some depth for breadth and constantly weigh trade-offs. The chapter explores how to balance hands-on work, business understanding, and the "knowledge pyramid" while avoiding traps like frozen-caveman thinking.

The Knowledge Pyramid

Knowledge divides into three layers: stuff you know, stuff you know you don't know, and stuff you don't know you don't know. Architects deliberately grow the middle layer — they need to recognize when to reach for something — rather than deepening the top.

Breadth Over Depth

Developers prize deep expertise; architects prize broad recognition. The job is matching capabilities to problems, which requires knowing that something exists more than knowing how it's implemented in detail.

Stale Expertise

Specialty knowledge decays. An architect who tries to maintain deep expertise across many areas fails on both fronts — they can't keep up and they don't have time to build the breadth their role actually needs.

Trade-Off Analysis

Every architectural choice involves balancing competing concerns. Topic-based messaging gives decoupling and extensibility; queue-based messaging gives contract control and security. Neither is "right" — the context decides.

Frozen Caveman Anti-Pattern

An architect who keeps raising the same irrational risk concern from a past project, ignoring current context. Recognizing this in yourself and others is the first defense.

Hands-On Without Bottlenecking

Architects should stay technical without becoming the critical-path coder. Techniques: build proofs of concept, tackle technical debt and bugs, automate with scripts, do code reviews — not own production features.

Knowledge Pyramid

Three-layer model of known, known-unknown, and unknown-unknown.

Technical Breadth

Wide, shallow knowledge prioritized over deep expertise for architects.

Technical Depth

Deep expertise in a narrow area, valued for senior developers.

Trade-Off Analysis

Structured comparison of competing options' pros and cons.

Proof of Concept

Small working code an architect builds to validate a design.

Frozen Caveman

Anti-pattern of anchoring on outdated risks from past trauma.

Stale Expertise

Specialty knowledge that loses value when not actively maintained.

Multiple choice

Which layer of the Knowledge Pyramid should architects deliberately try to expand the most?

• AStuff you know you don't know — the recognition layer.
• BStuff you know — the deep expertise layer.
• CStuff you don't know you don't know — by accident only.
• DNone of these — architects should focus equally on all three.

Spot the issue

An architect joins a project and immediately rejects asynchronous messaging because "the last team I worked with had message-ordering bugs that took us six months to debug." The current team is using Kafka with single-partition ordering and has no such risk. What's going on?

• AThe architect is correctly applying lessons learned from past experience.
• BFrozen caveman anti-pattern — anchoring on outdated risk regardless of current context.
• CThe team should accept the architect's domain experience as authoritative.
• DKafka cannot actually guarantee ordering, so the architect is right.

Multiple choice

Why does the book argue that architects should generally avoid being on the critical path of production feature work?

• AArchitects are not technically capable enough to ship features.
• BProduction work is below the architect's pay grade.
• CCritical-path feature work makes the architect a bottleneck and starves breadth-building activities.
• DHands-on coding undermines the architect's authority with the team.

True / False

Architects should match developers' depth of expertise in every technology the system uses.

• TrueTrue
• FalseFalse

Modularity

Modularity is the logical grouping of related code and the foundation of maintainable architecture. The chapter introduces measurable metrics — cohesion, coupling, connascence, and abstractness/instability — so architects can reason objectively rather than intuitively.

Cohesion

How related the elements inside a module are. The cohesion spectrum runs from functional (best, all elements serve one purpose) down through sequential, communicational, procedural, temporal, logical, to coincidental (worst, grouped by accident).

Coupling — Afferent and Efferent

Structural interdependence between modules. Afferent coupling counts incoming dependencies (who depends on me); efferent counts outgoing (who I depend on). Both are measurable with static analysis.

Abstractness and Instability

Abstractness = ratio of abstract artifacts (interfaces, abstract classes) to concrete ones. Instability = efferent / (afferent + efferent) — high instability means the module changes often due to dependencies.

Distance from the Main Sequence

The ideal balance is A + I = 1. Distance D = |A + I − 1|. Modules far from this line fall into the zone of uselessness (too abstract, no users) or the zone of pain (too concrete, too stable, can't change).

Connascence

Meilir Page-Jones's concept: two components are connascent if changing one forces a corresponding change in the other to maintain correctness. Static connascence happens at source-code level (name, type, position); dynamic happens at runtime (timing, value, identity).

Refactor Toward Weaker Connascence

The stronger the connascence, the harder maintenance becomes. The rule: refactor toward weaker forms (name is weakest, identity is strongest among static; value/identity strongest among dynamic). Strong connascence is tolerable only when locality is high.

Cohesion

Degree to which a module's elements belong together.

Coupling

Degree of interdependence between modules.

Afferent Coupling

Incoming dependencies on this module.

Efferent Coupling

Outgoing dependencies from this module.

LCOM

Lack of Cohesion in Methods — Chidamber–Kemerer metric.

Abstractness

Ratio of abstract to concrete elements in a module.

Instability

Efferent / total coupling; volatility under change.

Connascence

Page-Jones term for a relationship where one change forces another.

Multiple choice

A module has 12 outgoing dependencies and 2 incoming dependencies. What is its instability score?

• A0.14 — the module is very stable.
• B0.86 — the module is highly unstable.
• C6.0 — the ratio of efferent to afferent.
• DThe score cannot be computed without abstractness.

Multiple choice

Which form of cohesion is considered the strongest (best)?

• ACoincidental cohesion
• BTemporal cohesion
• CFunctional cohesion
• DLogical cohesion

Spot the issue

A module sits at abstractness = 0.9 and instability = 0.9 — lots of abstract types, and almost nothing depends on it. Where does it fall on Martin's diagram and what does that imply?

• AZone of pain — too concrete and too stable to change.
• BZone of uselessness — highly abstract code with no concrete consumers.
• COn the main sequence — ideally balanced.
• DOutside the diagram entirely; values cannot be valid.

True / False

Strong connascence between two components is always a defect that must be eliminated.

• TrueTrue
• FalseFalse

Architecture Characteristics Defined

The chapter defines what qualifies as an architecture characteristic and groups them into operational, structural, and cross-cutting categories. It warns against trying to support too many "-ilities" at once — every characteristic added makes the design harder.

The Three-Part Definition

A characteristic qualifies if it (1) specifies a non-domain consideration, (2) influences some structural aspect of the design, and (3) is critical or important to the application's success. Anything missing one of these isn't architectural.

Operational Characteristics

Performance, scalability, elasticity, availability, reliability, recoverability — the runtime behavior the system exhibits. Heavy overlap with DevOps concerns; usually the loudest to stakeholders.

Structural Characteristics

Configurability, extensibility, maintainability, portability, upgradeability — concerns about the code itself rather than its runtime behavior. Easier to measure; harder to sell to business.

Cross-Cutting Characteristics

Authentication, authorization, security, privacy, accessibility, legal compliance — concerns that touch every part of the system rather than living in one layer. They're often non-negotiable.

Scalability vs Elasticity

The two are routinely conflated. Scalability is sustained throughput growth (handling 10x users over a year); elasticity is bursty load handling (a flash sale spike). Architectures support them very differently.

Limit the Number of Characteristics

Supporting many "-ilities" creates conflicting trade-offs. Pick the few that matter most — typically the top three — and let the rest receive best-effort. The Vasa warship (Ch. 5) is the cautionary tale.

Operational Characteristic

Runtime concern like performance, availability, recoverability.

Structural Characteristic

Code-organization concern like maintainability, extensibility.

Cross-Cutting Characteristic

System-wide concern like security or accessibility.

Scalability

Sustained throughput growth as load rises over time.

Elasticity

Ability to absorb sudden bursts in load.

Agility

Composite of modularity, deployability, and testability.

ISO 25010

Standard taxonomy of software product quality attributes.

Synonym Wars

Vendor-coined "-ility" terms that erode shared vocabulary.

Multiple choice

An e-commerce site needs to handle a 50× traffic spike during a 30-minute flash sale and then return to normal. Which characteristic primarily drives this?

• AScalability
• BElasticity
• CReliability
• DMaintainability

Multiple choice

Which of the following is not part of the three-part definition of an architecture characteristic?

• AIt specifies a non-domain consideration.
• BIt influences some structural aspect of the design.
• CIt is critical or important to application success.
• DIt is listed in ISO 25010.

Spot the issue

An architect promises stakeholders the system will be "highly performant, scalable, elastic, available, resilient, maintainable, extensible, secure, and accessible — all top priority." What's the main problem?

• AThe list is missing reliability, which is the most important.
• BTrying to optimize for everything at once produces conflicting trade-offs and a fragile system.
• CThe list should be sorted alphabetically for clarity.
• DStakeholders will be reassured by a comprehensive list.

True / False

Cross-cutting characteristics like security can usually be addressed by adding a single layer or module to the system.

• TrueTrue
• FalseFalse

Identifying Architectural Characteristics

Architecture characteristics come from three sources: domain concerns, explicit requirements, and implicit domain knowledge. The chapter uses the Vasa warship as a cautionary tale about over-specified architectures and advocates the top-three rule for keeping characteristics tractable.

Three Sources of Characteristics

Characteristics come from domain concerns (stakeholder goals like "time to market"), explicit requirements (response times, concurrent users stated in user stories), and implicit knowledge the architect must infer (security, availability are usually assumed).

Translating Domain Concerns

Stakeholders speak business language. "User satisfaction" might mean response time or availability; "time to market" usually means agility (modularity + deployability + testability). The architect's job is the translation.

Top Three Rule

Limit the explicit characteristics the architecture is built to support to about three. More creates conflicting optimizations. The discipline is choosing which to drop, not which to add.

The Vasa Warship

The 17th-century Swedish warship Vasa was loaded with so many requested features — extra cannons, decorations, height — that it capsized on its maiden voyage. The architectural analog: over-specified systems collapse under their own weight.

Implicit vs Explicit Requirements

Some requirements are written down (response time < 100ms); others are assumed (the system is secure). Architects must surface implicit ones explicitly because untested assumptions cause production failures.

Composite Characteristics

Agility isn't a single characteristic — it's the composite of modularity, deployability, and testability. Stakeholders ask for the composite; architects must decompose it into measurable pieces.

Domain Concern

A business goal expressed in stakeholder language.

Explicit Requirement

A clearly stated requirement in the spec.

Implicit Requirement

A requirement assumed without being stated.

Top Three Rule

Limit explicit characteristics to about three priorities.

Vasa Anti-Pattern

Cramming too many characteristics until the system collapses.

Composite Characteristic

A characteristic made up of multiple measurable ones.

Domain-to-Architecture Mapping

Translating stakeholder concerns into technical traits.

Multiple choice

A stakeholder says "we need to get to market faster than our competitors." Which composite characteristic does this most directly imply?

• APerformance
• BAgility (modularity + deployability + testability)
• CReliability
• DSecurity

Spot the issue

A team's architecture document lists 11 critical architecture characteristics, all marked "high priority." A new architect joining the project should be most concerned about:

• AWhether the document is in the right wiki.
• BThe Vasa anti-pattern — too many characteristics produce conflicting trade-offs and design paralysis.
• CWhether the list is alphabetized.
• DWhether ISO 25010 has been cited.

Multiple choice

Which of the following is the least likely to be an *explicit* architectural requirement in a user story?

• A"Response time must be under 200ms at the 95th percentile."
• B"Support 10,000 concurrent users."
• C"Authenticate users via OAuth 2.0."
• D"The system should be secure."

True / False

A characteristic that emerges from implicit domain knowledge doesn't really qualify as an architecture characteristic until it's written down somewhere.

• TrueTrue
• FalseFalse

Measuring and Governing Architecture Characteristics

Characteristics that can't be measured can't be governed. The chapter introduces fitness functions — automated, objective tests of architectural integrity — borrowed from evolutionary computing, and surveys the metrics that make abstract "-ilities" testable.

Fitness Function

"Any mechanism that provides an objective integrity assessment of some architecture characteristic(s)." Borrowed from evolutionary algorithms; the central testable artifact in evolutionary architecture.

Operational Measurements

Performance, scalability, and availability come with well-known metrics: P50/P95/P99 latency, requests per second, uptime SLA. Loud and observable in production.

Structural Measurements

Code-level metrics like cyclomatic complexity, modularity, coupling, abstractness, and instability — measurable by static analysis at every commit.

Cyclomatic Complexity

Thomas McCabe's metric for independent execution paths through code. High values indicate methods doing too much; the standard threshold is 10, with anything higher flagged for decomposition.

Categories of Fitness Functions

Fitness functions are classified along several axes: atomic vs holistic, triggered vs continual, static vs dynamic, automated vs manual, temporal. The taxonomy helps architects design coverage that catches different failure modes.

Governance via Code

Tools like ArchUnit (Java) and NetArchTest (.NET) let architects write tests that assert architectural rules — for example, "the persistence layer never references the presentation layer." Violations fail the build like any other test.

Fitness Function

Objective, automated assessment of an architecture characteristic.

Atomic Fitness Function

Tests a single characteristic.

Holistic Fitness Function

Tests combinations of characteristics together.

Triggered Fitness Function

Runs on a specific event (CI build, deploy).

Continual Fitness Function

Runs constantly in production (monitoring).

Cyclomatic Complexity

McCabe's metric of independent execution paths.

ArchUnit

Java library for architectural test assertions.

NetArchTest

.NET equivalent of ArchUnit.

Multiple choice

Which definition best matches the book's description of a fitness function?

• AA unit test that checks a single business rule.
• BAny mechanism providing an objective integrity assessment of an architecture characteristic.
• CA deployment script that enforces production conventions.
• DA configuration file describing service dependencies.

Spot the issue

A team wants to enforce that no class in the `api` package directly imports from the `persistence` package. They add a code-review checklist item asking reviewers to check for violations. What's the best critique?

• ACode review is the right approach — automated rules are too rigid.
• BThe rule should be a triggered, automated fitness function (e.g., ArchUnit) so violations are caught in CI rather than relying on reviewer attention.
• CThe rule is unnecessary; layer violations don't matter in modern systems.
• DThe team should switch to a `presentation` package name first.

Multiple choice

Which fitness-function pair is correctly matched?

• ATriggered = runs continuously in production; Continual = runs only at deploy time.
• BAtomic = tests a combination of characteristics; Holistic = tests one.
• CTriggered = runs on a specific event; Continual = runs constantly in production.
• DStatic = needs deployment; Dynamic = checks source code only.

True / False

Cyclomatic complexity directly measures how many lines of code a method contains.

• TrueTrue
• FalseFalse

Scope of Architecture Characteristics

Traditional architecture treated characteristics as system-wide; modern distributed systems made that view obsolete. The chapter introduces the architecture quantum — an independently deployable unit with high functional cohesion and synchronous connascence — as the new scope of analysis.

The Architecture Quantum

"An independently deployable artifact with high functional cohesion and synchronous connascence." The unit at which characteristics can be measured and varied. A monolith is one quantum; a microservice system has many.

Independently Deployable

A quantum bundles everything it needs to run alone — including its database. Two "services" that share a database are part of the same quantum no matter how they look in code.

High Functional Cohesion at the Quantum Level

A quantum should map to a single meaningful business or domain capability, not an arbitrary slice of code. Cohesion at the quantum scale corresponds to DDD's bounded context.

Synchronous Connascence

Runtime dependency through synchronous calls binds parts of a quantum together. Asynchronous communication can decouple quanta, which is why event-driven and message-based patterns enable independent scaling.

Different Characteristics Per Quantum

In a microservices system, one service can be highly available while another is highly scalable. The quantum reframes "what's the system's availability" into "what's each quantum's availability."

Bounded Context Alignment

The architecture quantum naturally aligns with DDD's bounded context. This is why DDD became foundational to microservices — it provides the conceptual framing for where one quantum ends and the next begins.

Architecture Quantum

Independently deployable artifact with high functional cohesion and synchronous connascence.

Independently Deployable

Property of bundling all dependencies (including DB) for standalone operation.

Functional Cohesion

Cohesion organized around one purpose mapped to a domain concept.

Synchronous Connascence

Runtime coupling through synchronous calls.

Bounded Context

DDD concept where a model is internally consistent within explicit boundaries.

Static Coupling

How components are wired (dependencies, imports).

Dynamic Coupling

How components communicate at runtime (sync/async, transactional).

Monolithic Quantum

Traditional monolith treated as a single quantum.

Multiple choice

Service A and Service B are deployed as separate Docker containers and call each other over REST, but both write to the same PostgreSQL database. How many architecture quanta are present?

• ATwo — one per container.
• BOne — they share a database, so they're not independently deployable.
• CThree — counting the database as its own quantum.
• DIt depends on whether the database has separate schemas.

Multiple choice

Which DDD concept does the architecture quantum most directly align with?

• AAggregate root
• BValue object
• CBounded context
• DUbiquitous language

Spot the issue

An architect describes the company's microservices system as having "99.95% availability across the system." A reviewer pushes back. Why?

• A99.95% is too generous a target.
• BSystem-wide availability is not a meaningful unit of analysis in a multi-quantum architecture — characteristics apply per quantum.
• CAvailability should be expressed in minutes per year, not percent.
• DThe architect should use the term "uptime" instead of "availability."

True / False

Two services communicating only via asynchronous messaging are necessarily part of the same architecture quantum.

• TrueTrue
• FalseFalse

Component-Based Thinking

Components are the architect's primary building block — the physical manifestation of modules. The chapter distinguishes components from classes, contrasts technical and domain partitioning, and offers workflows like Event Storming and the actor/actions approach for identifying them.

Component as Architect's Unit

A component is a deployable, named, reusable piece — a library, layer, or subsystem. Architects work at the component level; developers fill in classes inside. The split clarifies who decides what.

Technical Partitioning

Organizing top-level components by technical capability: presentation, business logic, persistence. Maps naturally to traditional org charts (UI team, backend team, DBA team) — which is partly why it's so common.

Domain Partitioning

Organizing top-level components by business domain: CatalogCheckout, OrderTracking, UserProfile. Favored for agility, team alignment, and microservices because it minimizes the cross-team coordination needed for a single feature.

Conway's Law and the Inverse Maneuver

"Organizations design systems that mirror their communication structures." The inverse Conway maneuver reshapes teams on purpose to produce a desired architecture, exploiting the law in reverse.

Event Storming

A workshop technique from DDD where domain experts list every event the system processes; bounded contexts and components emerge from the clusters. Best for greenfield architectures with rich domain dynamics.

Actor/Actions and Workflow Approaches

Two alternatives to Event Storming. Actor/actions identifies user roles and their actions — fits well-defined user types. Workflow models around process steps — fits domains without clear events.

Component Identification Workflow

An iterative process: identify initial components, assign user stories to them, analyze roles and responsibilities, evaluate against architecture characteristics, restructure as needed. Components are refined, not designed once.

Component

Physical building block — a deployable, named unit of classes/modules.

Technical Partitioning

Decomposition by technical role (UI, business, persistence).

Domain Partitioning

Decomposition by business domain or subdomain.

Subdomain

A discrete business capability within the overall domain.

Conway's Law

Systems mirror the communication structures of the orgs that build them.

Inverse Conway Maneuver

Restructuring teams to drive a desired architecture.

Event Storming

DDD workshop technique that discovers components via domain events.

Actor/Actions Approach

Component discovery via user roles and their actions.

Workflow Approach

Component discovery via business workflow steps.

Multiple choice

A team builds a new e-commerce platform with separate components for `presentation-layer`, `business-rules`, and `persistence`. Which partitioning style does this represent?

• ADomain partitioning
• BTechnical partitioning
• CEvent-driven partitioning
• DQuantum partitioning

Spot the issue

A company wants a microservices architecture but its teams are still organized as `frontend-team`, `backend-team`, and `database-team`. After six months they have three large services aligned with those teams rather than with business domains. What's the lesson?

• AMicroservices simply doesn't work at this company.
• BConway's Law caught them — system structure mirrored team structure rather than the intended domain split.
• CThe teams need better technical training in microservices.
• DThe architecture is fine; team labels don't affect system design.

Multiple choice

Which component-discovery technique is best suited to a greenfield system in a domain rich with business events?

• AActor/actions approach
• BWorkflow approach
• CEvent Storming
• DTop-down layered decomposition

True / False

Architects typically design components at the class level, leaving package/module structure to developers.

• TrueTrue
• FalseFalse

Foundations (of Architecture Styles)

Architecture styles are named sets of structural decisions and trade-offs that give architects shared vocabulary. The chapter distinguishes styles from patterns, surveys fundamental options (Big Ball of Mud, Unitary, Client/Server), and lays out the eight fallacies of distributed computing every architect must respect.

Styles vs Patterns

A style describes the system's overall topology and the trade-offs that come with it. A pattern is a lower-level reusable solution within a style (circuit breaker, CQRS, saga). Styles are the question; patterns are tactics inside the answer.

Big Ball of Mud

Foote and Yoder's anti-pattern name for systems with no discernible architecture — haphazard, undocumented, with cascading change impact. The default outcome when architecture is neglected, not a style anyone chooses.

Technical vs Domain Partitioning at the Style Level

Layered, pipeline, and microkernel are technically partitioned monoliths. Service-based, event-driven, space-based, and microservices are typically domain-partitioned and distributed. The split affects nearly every characteristic the style supports.

The Eight Fallacies of Distributed Computing

Deutsch and Gosling's list (Sun, 1994) of false assumptions about networks: the network is reliable, latency is zero, bandwidth is infinite, the network is secure, topology never changes, there is only one administrator, transport cost is zero, the network is homogeneous. Every one bites distributed systems.

Distributed Logging and Transactions

Distribution multiplies operational concerns: you can't `tail -f` across 50 services, ACID transactions don't span network calls without painful coordination, and contracts between services must be versioned because deployments are independent.

Stamp Coupling

A subtle distributed-system anti-pattern: passing larger data structures than the recipient needs (sending a whole order object when only the order ID is required). Wastes bandwidth and creates implicit coupling on shared field shapes.

Architecture Style

Overarching structure defining components and their relationships.

Architecture Pattern

Lower-level reusable solution within a style.

Big Ball of Mud

Anti-pattern of unstructured, undocumented code.

Stamp Coupling

Passing larger data structures than needed across services.

Eventual Consistency

Data converging to a consistent state over time, not immediately.

Saga

Sequence of local transactions with compensating actions for distributed workflows.

Circuit Breaker

Pattern that stops calls to a failing remote service to prevent cascade.

Topology

Arrangement and interconnection of architectural components.

Multiple choice

A new architect proposes building a distributed system without budgeting for latency, retries, or network failures. Which fallacy of distributed computing are they violating most directly?

• AThe network is homogeneous
• BThe network is reliable AND latency is zero
• CTransport cost is zero
• DThere is only one administrator

Multiple choice

Which of the following is a pattern, not a style?

• AEvent-driven architecture
• BMicroservices
• CCircuit breaker
• DLayered architecture

Spot the issue

A microservice exposes a `getOrder(orderId)` endpoint that returns the full order object — line items, customer details, shipping address, payment info — even when callers only need the order status. What anti-pattern is this?

• AStamp coupling
• BBig Ball of Mud
• CEventual consistency
• DSaga overuse

True / False

The "Big Ball of Mud" is one of the formal architecture styles described in the book, distinct from layered and microservices.

• TrueTrue
• FalseFalse

Layered Architecture Style

The layered (n-tier) architecture organizes components into horizontal technical layers — presentation, business, persistence, database — each with a defined role. It's the de facto starting style for small applications: simple, cheap, well-understood, but constrained by monolithic deployment and technical partitioning.

Topology and Layers

Four standard layers: presentation, business, persistence, database. The number is flexible — some systems add a services layer or split persistence. Technically partitioned, not domain-partitioned.

Layers of Isolation

Closed layers force requests to pass through every layer in sequence. The benefit: changing the database doesn't ripple to the presentation layer because the persistence layer absorbs the change. Isolation is the whole point.

Closed vs Open Layers

A closed layer must be passed through; an open layer can be bypassed. Open layers are useful for shared utilities (logging, common services) but every open layer increases coupling.

Architecture Sinkhole Anti-Pattern

When requests traverse multiple layers performing only trivial pass-through with no real logic, the layering adds overhead with no payoff. The 80/20 rule: tolerable if under 20% of requests behave this way.

Why Layered Is So Common

Maps naturally to traditional org charts (UI team, backend team, DBA team) — Conway's Law in action. Low complexity, low cost, easy to learn. Often the right starting point even when it won't be the final answer.

Star-Rating Profile

Excellent at cost (5) and simplicity (5). Weak at deployability, elasticity, evolutionary, fault tolerance, modularity, scalability (all 1). Reliability moderate (3), performance and testability low (2).

Closed Layer

A layer that must be passed through; cannot be bypassed.

Open Layer

A layer that can be skipped by callers above it.

Architecture Sinkhole Anti-Pattern

Requests traverse layers without meaningful processing.

Layers of Isolation

Principle that closed layers contain change impact.

Technical Partitioning

Grouping components by technical role rather than business domain.

Presentation Layer

User-facing UI and controllers.

Business Layer

Domain rules, workflows, validations.

Persistence Layer

Data-access mediation via DAOs, repositories, ORM.

Monolithic Deployment

Single deployment unit containing all layers.

Multiple choice

A request enters the presentation layer, calls the business layer (which just delegates), calls the persistence layer (which just delegates), and returns to the presentation layer unchanged. If more than 20% of requests follow this path, what's happening?

• AThe system is correctly applying the layers-of-isolation principle.
• BThe system suffers from the architecture sinkhole anti-pattern.
• CThe business layer should be removed entirely.
• DThe system has too few layers.

Multiple choice

Which two characteristics does the layered architecture rate highest (5 stars)?

• AScalability and elasticity
• BCost and simplicity
• CDeployability and modularity
• DFault tolerance and performance

Spot the issue

A team makes the persistence layer "open" so that the presentation layer can read directly from the database for performance reasons. A year later, a schema change breaks the UI in unexpected places. What principle did they violate?

• ALayers of isolation — the persistence layer's whole job is to absorb data-shape changes so they don't ripple up.
• BArchitecture sinkhole — the presentation layer was doing too little work.
• CConway's Law — the team structure didn't match.
• DNone — open layers are always fine.

True / False

The layered architecture is a domain-partitioned style.

• TrueTrue
• FalseFalse

Pipeline Architecture Style

Also known as pipes-and-filters, the pipeline style structures processing as a sequence of independent filters connected by unidirectional pipes — the pattern behind Unix shells, ETL tools, Apache Camel, and build pipelines. Strengths are compositional reuse and modularity; weaknesses come from monolithic deployment.

Pipes and Filters

Two component types: pipes are unidirectional point-to-point channels carrying data; filters are self-contained, stateless, single-purpose processors. Data flows one way through the chain.

Four Filter Types

Producers originate data (sources). Transformers modify input and produce output (map). Testers evaluate conditions and conditionally emit (filter/reduce). Consumers are terminal sinks. Every filter belongs to one of these four roles.

Compositional Reuse

Filters are interchangeable building blocks. New pipelines come together by re-arranging existing filters instead of writing new code — like piping Unix utilities. This is the style's main draw.

Common Uses

ETL pipelines (Apache Camel, AWS Data Pipeline), electronic data interchange, CI/build pipelines, stream processing, and complex event processing. Anywhere data flows linearly through transformation stages.

Monolithic Deployment Constraint

Despite excellent internal modularity, filters typically ship as one deployable unit — one architecture quantum. You can't independently scale or fail-isolate one filter without breaking the metaphor.

Star-Rating Profile

Top scores in cost (5), simplicity (5), and modularity (5). Moderate in deployability, evolutionary, testability (3). Weak in elasticity, fault tolerance, scalability (1).

Pipe

Unidirectional point-to-point channel transferring data between filters.

Filter

Self-contained, stateless processing unit doing one task.

Producer

Filter that originates data into the pipeline.

Transformer

Filter that modifies input and produces output (map-style).

Tester

Filter that evaluates input and conditionally emits output (filter/reduce-style).

Consumer

Terminal filter performing a final action.

Compositional Reuse

Re-using and reordering filters to construct new pipelines.

Pipes-and-Filters

Alternative name for the pipeline style.

Multiple choice

A filter receives a stream of orders, examines each one, and only forwards orders worth more than $100. Which filter type is this?

• AProducer
• BTransformer
• CTester
• DConsumer

Multiple choice

What is the biggest architectural limitation of the pipeline style despite its strong modularity?

• AFilters cannot communicate with each other.
• BThe pipeline as a whole is a monolithic deployment — typically one architecture quantum.
• CPipes only support binary data.
• DTesters cannot be reused across pipelines.

Spot the issue

A team builds an ETL pipeline where one filter both transforms records *and* writes them to the database at the same time. What pipeline principle does this violate?

• AThe filter is doing both transformer and consumer work — filters should be single-purpose, and pipes should connect them.
• BFilters should be stateful — combining transform and write makes it stateless, breaking the style.
• CPipes must carry the same data type end-to-end, and a writer changes the payload format.
• DThe filter should also act as a producer; otherwise the pipeline has no source.

True / False

A canonical example of pipeline architecture in everyday use is Unix shell piping (`cat file | grep foo | wc -l`).

• TrueTrue
• FalseFalse

Microkernel Architecture Style

The microkernel (a.k.a. plug-in) architecture splits an application into a minimal core system and independent plug-ins that extend it. It's the dominant pattern for product software (Eclipse, IntelliJ, browsers, Jenkins) and any business app that needs extensibility or customer-specific rules.

Core System

Holds the minimum functionality required to run the application — the general workflow, the "happy path." Can itself be internally layered. The core never knows the specifics of any plug-in.

Plug-In Components

Independent, standalone modules that contain specialized processing, custom rules, or optional features. Isolated from each other so one plug-in's bug doesn't crash siblings.

Plug-In Registry

The mechanism the core uses to discover, locate, and invoke available plug-ins. Holds names, contracts, and protocols. Without it the core has no way to find the plug-ins.

Contracts

Standardized interfaces between core and plug-ins — XML, JSON, objects, or interface definitions. Versioning is critical: third-party plug-ins must keep working as the core evolves.

Core-to-Plug-In Communication

Usually in-process method calls. Can be REST or messaging when plug-ins are remote, but that adds distributed-system complexity. In-process keeps the style monolithic and cheap.

Why It Fits Product Software

Insurance, tax, and IDE products all share the pattern: a stable core with jurisdiction-specific or domain-specific rules that vary by customer. Plug-ins isolate variation; the core stays small and well-tested.

Core System

Minimal essential functionality of the application.

Plug-In Component

Independent module that extends or specializes the core.

Plug-In Registry

Catalog the core uses to find plug-ins and their contracts.

Contract

Defined interface/data format between core and plug-in.

Extensibility

Ability to add functionality without modifying the core.

Plug-In Architecture

Synonym for microkernel architecture.

Product-Based Application

Software shipped/installed and extended by customers or third parties.

Domain Partitioning

Organizing code around business domains.

Multiple choice

A tax-preparation product ships a stable engine and adds per-country tax rules as separate modules customers install. Which architecture style does this most closely match?

• ALayered
• BMicrokernel (plug-in)
• CEvent-driven
• DMicroservices

Multiple choice

What does the plug-in registry hold?

• AThe compiled bytecode of every plug-in, embedded inside the core.
• BThe names, contracts, and protocols by which the core can find and call plug-ins.
• CThe shared business state that all plug-ins read from and write to.
• DThe runtime telemetry and logs emitted by each plug-in.

Spot the issue

A team builds a microkernel-style product but lets two plug-ins call each other directly, bypassing the core. What's the risk?

• APlug-ins lose their isolation — a change in one plug-in's interface now ripples to another, defeating the style's modularity benefits.
• BPerformance will drop because peer calls are slow.
• CThe plug-in registry will refuse the call.
• DNothing — plug-in to plug-in calls are encouraged in this style.

True / False

Eclipse, IntelliJ, and most modern web browsers are commonly cited as examples of microkernel architecture in production.

• TrueTrue
• FalseFalse

Service-Based Architecture Style

Service-based architecture is the pragmatic middle ground between monoliths and microservices — a "distributed macro-layered" style with a separate UI, 4–12 coarse-grained domain services, and a single shared database. It captures most service-decomposition benefits while avoiding microservices' operational complexity.

Topology

Separately deployed user interface, an optional API layer, 4–12 coarse-grained domain services, and a shared monolithic database. The services are independently deployable; the database is not.

Coarse-Grained Domain Services

Each service represents a large slice of business functionality, not a single endpoint. Average ~7 services per application. Coarse granularity is the deliberate choice — it sidesteps microservices' granularity headaches.

Shared Monolithic Database

All services share one database, optionally logically partitioned by domain. The big win: ACID transactions still work and SQL joins are possible. The trade-off: schema changes can ripple across services.

ACID Transactions Across Services

Because the database is shared, services can participate in traditional ACID transactions. No sagas, no eventual consistency, no compensating actions. This alone is why many teams choose service-based over microservices.

When to Choose Service-Based

Domain-driven business applications where transactional integrity matters more than ultra-fine-grained scaling; teams migrating from a monolith but not ready for full microservices; systems where 4–12 services map cleanly to the business.

Star-Rating Profile

Strong across the board with no five-star ratings: cost 4, simplicity 4, deployability 4, evolutionary 4, fault tolerance 4, modularity 4, reliability 4, testability 4. Moderate elasticity, scalability, performance (3).

Domain Service

Coarse-grained, independently deployed service representing a business domain.

Macro-Layered Structure

UI / services / database arranged as distributed layers.

API Layer

Optional reverse-proxy/gateway routing requests to domain services.

Coarse-Grained Service

Service encompassing a broad business capability.

Shared Monolithic Database

Single database supporting all domain services.

Logical Database Partitioning

Schema organized by domain so changes affect only one service.

Architectural Modularity

Degree to which architecture supports independent change and deployment.

Domain Partitioning

Decomposing the system by business domain rather than technical concern.

Multiple choice

Approximately how many domain services does a typical service-based architecture have?

• A1 — it's a monolith.
• B4 to 12, averaging around 7.
• C50 to 100, like microservices.
• DExactly 3 — UI, business, data.

Multiple choice

Which property does service-based architecture preserve that microservices generally cannot?

• AIndependent deployability of services.
• BACID transactions across multiple services.
• CService mesh observability.
• DBounded context isolation.

Spot the issue

A team chooses service-based and immediately starts decomposing their domain into 40 fine-grained services, each with its own database. What have they actually built?

• AMicroservices, not service-based — they've discarded both defining properties (coarse granularity and shared DB).
• BService-based architecture with extra granularity that just needs tuning.
• CA distributed monolith because the services are still too coupled.
• DEvent-driven architecture by accident.

True / False

Service-based architecture rates 5 stars on scalability, matching microservices.

• TrueTrue
• FalseFalse

Event-Driven Architecture Style

Event-driven architecture (EDA) is a distributed, asynchronous style built from decoupled processors that react to events. It excels at scalability, elasticity, and performance for reactive workflows but is complex to design, debug, and test. EDA can stand alone or hybridize with other styles.

Request-Based vs Event-Based

Request-based systems use a deterministic orchestrator directing synchronous requests; event-based systems react asynchronously to events, enabling dynamic non-deterministic flows. The mental model is fundamentally different.

Broker Topology

No central mediator. Initiating events flow through a lightweight broker (Kafka, RabbitMQ); processors react and emit further processing events in a chain. Highly decoupled, scalable, performant — but no workflow control or central error recovery.

Mediator Topology

A central event mediator orchestrates multi-step workflows through queues and channels. Better error handling, recoverability, and workflow visibility — at the cost of coupling and reduced scalability/performance versus broker.

Asynchronous Performance Advantage

Fire-and-forget messaging dramatically improves responsiveness because callers don't wait. This is the main reason EDA rates 5 stars on performance.

Workflow Event Pattern

Error handling without bottlenecking the main flow. Failed events get sent to a workflow delegate that repairs and resubmits them, keeping the primary pipeline responsive while still recovering.

Preventing Data Loss

Use persistent queues, synchronous send with broker acknowledgments, client-acknowledge mode on consumers, and "last participant support" so events aren't lost between broker, processor, and database.

Star-Rating Profile

Five-star on elasticity, evolutionary, fault tolerance, performance, scalability. One-star on simplicity. The pattern that buys all the runtime characteristics is also the hardest to design and debug.

Event Processor

Component that listens for and reacts to events.

Initiating Event

Event that kicks off a business process.

Processing Event

Event generated by a processor while handling an initiating event.

Event Channel

Queue or topic used to transport a category of events.

Event Broker

Lightweight, decentralized routing mechanism (Kafka, RabbitMQ).

Event Mediator

Central orchestrator of multi-step event workflows.

Broker Topology

Decentralized EDA with no orchestration.

Mediator Topology

Centralized EDA with orchestrated workflows.

Workflow Event Pattern

Error-handling pattern delegating failed events to a repair component.

Multiple choice

A team wants the highest possible scalability and performance for a reactive, real-time analytics system with simple workflows. Which EDA topology should they pick?

• AMediator topology — central coordination scales best.
• BBroker topology — decentralized routing gives the best scalability and performance.
• CHybrid layered/EDA — adds simplicity.
• DService-based with events tacked on.

Multiple choice

EDA rates 5 stars on multiple characteristics but 1 star on which one?

• APerformance
• BScalability
• CSimplicity
• DElasticity

Spot the issue

A team uses broker topology for an end-to-end order workflow with twelve sequential steps. Three months in, they cannot tell which step a given order is stuck on or how to recover from partial failures. What should they have done differently?

• AUsed mediator topology — central orchestration provides the workflow control and recoverability that broker lacks.
• BAdded more brokers in parallel.
• CSwitched to synchronous communication entirely.
• DLogged more aggressively at each step.

True / False

Asynchronous messaging in EDA improves responsiveness because callers don't wait for processing to complete.

• TrueTrue
• FalseFalse

Space-Based Architecture Style

Space-based architecture targets extreme scalability, elasticity, and concurrent user volume by removing the central database as a synchronous constraint. It uses replicated in-memory data grids distributed across processing units with asynchronous database updates. Best for spiky, unpredictable load — concert tickets, online auctions, flash sales.

The Database Bottleneck Problem

Most architectures hit a wall when the database becomes the synchronous constraint. Space-based removes the database from the request path entirely; reads and writes happen in distributed in-memory grids and propagate asynchronously to the DB.

Processing Units

Each processing unit contains the application logic, an in-memory data grid, and a replication engine that propagates changes to peer units. Multiple processing units run concurrently, sharing state through replication.

Virtualized Middleware

Four components manage the system: messaging grid (request routing), data grid (replicated in-memory cache), processing grid (optional cross-unit orchestration), deployment manager (dynamic processing-unit lifecycle for elasticity).

Data Pumps and Asynchronous Persistence

Data changes flow from processing units to the database via persistent queues — the data pump. A separate data writer drains the queue and updates the DB. Reads at startup come from a data reader. Writes never block requests.

Data Collisions

The cost of replicated caching: one unit's update can be overwritten by another's replication. Collision risk grows with cache size, update frequency, and number of instances — quantifiable as `(updates × instances²) / replication latency`.

When to Use Space-Based

Unpredictable, spiky load that traditional architectures can't absorb: concert ticket sales, flash sales, online auctions. The cost and complexity are justified only when conventional scaling falls over.

Star-Rating Profile

Five-star on elasticity, performance, scalability — the whole point. One-star on cost and simplicity. Moderate everywhere else. Pick it only when you genuinely need those three fives.

Messaging Grid

Manages incoming requests and session state via load balancing.

Data Grid

Replicated in-memory cache distributed across processing units.

Processing Grid

Optional component orchestrating cross-unit requests.

Deployment Manager

Dynamically starts/stops processing units for elasticity.

Data Pump

Sends data asynchronously via persistent queue to the database.

Data Writer

Drains the data pump's queue and persists to the database.

Data Reader

Reads from the database to seed processing units on startup.

Replicated Cache

In-memory cache duplicated across all processing units.

Multiple choice

Space-based architecture solves which fundamental scaling problem?

• ANetwork latency between services.
• BThe central database becoming the synchronous bottleneck.
• CService-to-service authentication.
• DCode complexity in business logic.

Spot the issue

A team picks space-based for a low-traffic internal admin app with predictable steady load. After six months, infrastructure cost has tripled with no performance benefit. What went wrong?

• ASpace-based is wrong for steady, predictable load — its cost and complexity only pay off for genuinely spiky, high-volume scaling needs.
• BThe data grid was misconfigured.
• CThey should have used more processing units.
• DNothing — this is the expected cost.

Multiple choice

What is the role of the data pump in space-based architecture?

• ATo read fresh data from the database into each processing unit's cache.
• BTo asynchronously transfer data changes from processing units to the database via persistent queue.
• CTo synchronously update the database before returning to the caller.
• DTo replicate cache state between processing units.

True / False

Data collisions in space-based architecture become more likely as cache size, update frequency, and the number of processing units all increase.

• TrueTrue
• FalseFalse

Orchestration-Driven Service-Oriented Architecture

A late-1990s/early-2000s enterprise style centered on reuse and a central orchestration engine (ESB) coordinating layered services. Heavy reuse created tight coupling, transactional complexity, and coordinated deployment headaches. Studied today mainly as a cautionary tale and the precursor that motivated microservices.

Reuse as Organizing Principle

The architecture was driven by the business mandate to maximize reuse — amortize expensive licensed software and headcount. The instinct was right; the execution coupled everything together and produced the opposite of agility.

Service Taxonomy

Strict layering of business services (abstract domain entry points), enterprise services (atomic reusable behaviors), application services (single-app needs), and infrastructure services (logging, auditing). The orchestration engine wires them together.

The Orchestration Engine (ESB)

The Enterprise Service Bus is the heart of the architecture. It declaratively defines workflows, mediates protocols, and manages transaction boundaries. Powerful in theory; in practice, a central choke point that owned far too much logic.

Technical Partitioning Pitfalls

Splitting services by technical capability rather than domain meant every business change rippled across multiple service layers. The agility costs were enormous and largely invisible until the system was committed.

Coupling Through Reuse

Aggressive reuse coupled producers and consumers together; changes to a reusable service required coordinated, risky deployments across many consumers. The "reuse pays off" promise inverted into "reuse pays you back with interest."

Worst of Both Worlds

SOA combined the disadvantages of monoliths (coordinated deploys, coupling) with the disadvantages of distributed systems (network failures, complexity). It earned 1-star ratings on cost, simplicity, deployability, evolutionary, performance, and testability.

Business Service

Abstract, code-free domain entry point (e.g., ExecuteTrade).

Enterprise Service

Fine-grained, atomic, reusable behavior shared across the company.

Application Service

One-off service serving a single application.

Infrastructure Service

Provides operational concerns (logging, auditing).

Orchestration Engine (ESB)

Central declarative coordinator wiring services together.

Mediator

Translates between protocols/formats for heterogeneous services.

Heterogeneous Interoperability

SOA's strength — bridging differing platforms via standard transports.

Service Taxonomy

The four-layer SOA categorization of services.

Multiple choice

What was the primary organizing principle of orchestration-driven SOA?

• ADecoupling and independent deployability.
• BMaximum reuse of services to amortize licensing and headcount costs.
• CEvent-driven asynchronous communication.
• DDomain-driven design.

Multiple choice

Which of the following is not part of the SOA service taxonomy?

• ABusiness service
• BEnterprise service
• CApplication service
• DQuantum service

Spot the issue

A team building a new system in 2024 proposes a heavy reuse-driven service-oriented architecture coordinated by a central ESB. What's the strongest objection?

• AESBs are inherently incompatible with REST and JSON, forcing the team to use only SOAP.
• BThe reuse-driven coupling and ESB choke point produced consistently poor outcomes — this is exactly the cautionary tale microservices was a reaction to.
• CSOA cannot satisfy any of the architecture characteristics a modern business needs.
• DNothing — orchestration-driven SOA is still the recommended default for greenfield systems.

True / False

Orchestration-driven SOA rates highly on agility and evolutionary characteristics.

• TrueTrue
• FalseFalse

Microservices Architecture

A highly distributed style inspired by DDD's bounded context — each service is independently deployable, owns its data, and is purpose-built around a single domain. Microservices prioritize decoupling above all else (even accepting code duplication) and avoid cross-service transactions. The hardest design problem is getting granularity right.

Bounded Context Per Service

Each microservice owns its code, data, and dependencies internally. Nothing internal is shared outside the boundary. The bounded context is the unit of independence, not just the unit of meaning.

Granularity Is the Hardest Problem

Too fine-grained → chatty inter-service communication, distributed transaction headaches. Too coarse → reintroduces internal coupling. The right answer is domain workflows, not lines of code or class count.

Avoid Reuse, Prefer Duplication

Shared libraries reintroduce coupling — a breaking change in `common-utils` cascades across every consumer. Microservices accept duplication as the price of independence; it's a counterintuitive but central design rule.

Data Isolation

Each service owns its database/schema. No shared schemas, no cross-service joins, no cross-service ACID transactions. This is non-negotiable in the style — sharing data sneaks coupling back in.

Choreography vs Orchestration

Choreography — peer-to-peer messaging — preserves decoupling but makes complex workflows hard to reason about. Orchestration — central mediator — eases workflows but reintroduces coupling. The trade-off is constant.

Sagas and Distributed Transactions

When transactions truly span services, use the saga pattern: a sequence of local transactions with compensating actions for rollback. Complex and to be used sparingly — most distributed-transaction needs are signs of wrong service boundaries.

Sidecars and Service Mesh

Cross-cutting concerns (logging, monitoring, security, retries) live in sidecar containers co-located with each service. Together, sidecars form the service mesh — a unified control plane for observability and policy.

Star-Rating Profile

Five-star on deployability, elasticity, evolutionary, fault tolerance, scalability. One-star on cost and simplicity. The most operationally expensive style, justified only when those five characteristics genuinely matter.

Bounded Context

DDD concept; the boundary within which a model is internally consistent.

Choreography

Peer-to-peer service interaction without a central coordinator.

Orchestration

Service interaction directed by a central coordinator.

Saga

Long-running distributed transaction using compensating actions for eventual consistency.

Sidecar Pattern

Co-located helper container handling operational concerns.

Service Mesh

Aggregated control plane formed by sidecars across services.

Service Discovery

Mechanism for dynamically locating service instances.

Micro-Frontend

UI components emitted independently by each service.

Multiple choice

According to the book, which is the hardest design problem in microservices?

• AChoosing the right HTTP framework.
• BGetting service granularity right — too fine causes chatty communication, too coarse reintroduces coupling.
• CSecuring inter-service communication.
• DDeploying to Kubernetes.

Multiple choice

Why do microservices generally prefer duplication over reuse?

• ADuplication compiles faster.
• BShared libraries reintroduce coupling, defeating independent deployability.
• CReused code violates DDD bounded contexts by definition.
• DDuplication makes services easier to test.

Spot the issue

A team builds microservices but lets two services share the same PostgreSQL schema "to avoid duplicating order data." Six months later they cannot deploy either service independently because schema changes break both. What principle did they violate?

• AChoreography over orchestration for cross-service workflows.
• BSaga pattern compliance for distributed transactions.
• CData isolation — each microservice must own its data; sharing schemas collapses two services into one quantum.
• DService mesh routing through sidecars.

True / False

Sagas are the recommended default for any workflow spanning multiple microservices.

• TrueTrue
• FalseFalse

Choosing the Appropriate Architecture Style

There is no universally best architecture style; selection is context-dependent and the right answer shifts as the ecosystem evolves. Architects derive style from domain understanding, required characteristics, data architecture, and organizational factors — and document the choice with ADRs and fitness functions.

Architecture Is a Snapshot in Time

Decisions appropriate today may be obsolete tomorrow. Cloud, containers, DevOps, and open source dominance keep shifting which trade-offs are acceptable. Re-evaluate periodically; don't treat past style choices as eternal.

Three Primary Decisions

Every architecture style boils down to three big choices: monolith vs distributed, where data lives and how it's partitioned, and synchronous vs asynchronous communication. Everything else flows from these.

Synchronous by Default

Use synchronous communication unless asynchronous is genuinely required. Async adds significant complexity (error handling, ordering, observability) — the burden of proof falls on the case for async, not the case against.

Domain Drives Topology

Different bounded contexts may need different architecture characteristics. If a single style can't satisfy all of them, distributed is justified. If one style satisfies everything, distributed is overkill.

Data Architecture Collaboration

Architects must partner with DBAs and data architects from the start. Data placement profoundly constrains style choices — picking microservices then "figuring out data later" is a path to failure.

Outputs of the Design Process

The choice produces two durable artifacts: Architecture Decision Records (ADRs) documenting the significant decisions and fitness functions governing the characteristics over time. Neither is optional.

Architecture Quantum

Independently deployable artifact with high functional cohesion and synchronous connascence.

Domain Partitioning

Organizing the system by business domain.

Technical Partitioning

Organizing by technical capability or layer.

Fitness Function

Objective integrity assessment of an architecture characteristic.

Architecture Decision Record (ADR)

Documenting an architecturally significant decision.

Monolith vs Distributed

The most fundamental topology choice.

Data Residency / Partitioning

Where data lives and how it's divided.

Communication Synchronicity

Whether interactions are blocking request/response or non-blocking.

Multiple choice

Which is not one of the three primary architectural decisions the chapter highlights?

• AMonolith vs distributed.
• BWhere data lives and how it's partitioned.
• CSynchronous vs asynchronous communication.
• DWhich programming language to use.

Multiple choice

What does the book recommend when an architect is uncertain whether communication between two services should be sync or async?

• AAlways pick async — it's modern and decoupled.
• BAlways pick sync — async never works at scale.
• CDefault to sync unless async is genuinely required; the complexity tax of async needs justification.
• DToss a coin — both are equivalent.

Spot the issue

A team picks microservices because "it's the modern best practice," ignoring that their single-bounded-context CRUD application doesn't need independent deployability, fault isolation, or scalability. What's the main error?

• AThe architecture should be context-driven; "modern best practice" is not a justification — microservices brings 1-star cost and simplicity for no payoff here.
• BThey should have picked event-driven instead.
• CMicroservices is wrong because their team is too small.
• DNothing — microservices is always the right answer.

True / False

Once an architecture style is chosen, it should generally remain fixed for the life of the system because re-evaluation is too disruptive.

• TrueTrue
• FalseFalse

Architecture Decisions

Decisions are the architect's core deliverable — not diagrams. They must be gathered carefully, justified completely, documented systematically, and communicated to the right stakeholders. Architecture Decision Records (ADRs) are the canonical documentation; three anti-patterns undermine decision quality.

Architecturally Significant Decisions

Decisions affecting structure, non-functional characteristics, dependencies, interfaces, or construction techniques. Everything else is design and belongs to the developers. Knowing which is which is the architect's filter.

Last Responsible Moment

Decisions should be deferred until enough information is available — but not later. Deciding too early locks in assumptions; deciding too late wastes effort. "Just enough information" is the bar.

ADR Template

A short structured document with Title (sequentially numbered), Status (Proposed / Accepted / Superseded), Context (forces and alternatives), Decision (prescriptive "we will…" statement), Consequences (positive and negative impacts), and optional Compliance and Notes.

Single System of Record

Decisions must live in one durable, broadly accessible location — a wiki, not Git, never email. Discoverability by non-developers is the requirement; if stakeholders can't find decisions, they didn't happen.

Covering Your Assets Anti-Pattern

The architect avoids making decisions out of fear of being wrong — passing the buck or leaving the decision implicit. Cure: decide at the last responsible moment with sufficient (not perfect) information, then collaborate to validate quickly.

Groundhog Day Anti-Pattern

The same decision gets debated over and over because no one understands why it was made. Cure: always document both technical *and* business justification. Once stakeholders understand the rationale, they stop relitigating.

Email-Driven Architecture Anti-Pattern

Decisions communicated by email and then lost. Cure: maintain a single durable system of record (wiki); use email only to *notify* stakeholders of a decision with a link to the ADR — never as the storage medium.

Architecture Decision Record (ADR)

Structured doc describing a single architecturally significant decision.

Status (in ADR)

Lifecycle marker — Proposed, Accepted, or Superseded.

Context (in ADR)

Forces, constraints, and alternatives motivating the decision.

Consequences (in ADR)

Resulting impacts and trade-offs.

Compliance (in ADR)

How adherence will be measured and governed.

Last Responsible Moment

Latest point at which a decision can be made without negative consequences.

System of Record

Single authoritative store of decisions.

Covering Your Assets

Anti-pattern of avoiding decisions out of fear.

Multiple choice

According to the chapter, which is the canonical storage location for architecture decisions?

• AInline comments in source code.
• BEmail threads to all stakeholders.
• CA wiki or dedicated decision store accessible to non-developers.
• DThe architect's personal notes.

Multiple choice

A team keeps relitigating the choice of message broker — every quarter someone proposes switching. The original ADR documents only *what* was chosen, not *why*. Which anti-pattern is this?

• ACovering Your Assets
• BGroundhog Day
• CEmail-Driven Architecture
• DStamp Coupling

Spot the issue

An architect is asked to choose between two databases. They respond, "Let the team decide — they'll have to live with it." A year later, the team made an inconsistent choice across services and is suffering for it. Which anti-pattern is this?

• ACovering Your Assets — the architect avoided making the call out of fear of being wrong.
• BGroundhog Day — the decision was relitigated.
• CEmail-Driven Architecture — it was sent by email.
• DBig Ball of Mud — the system is messy.

True / False

The ADR template's "Consequences" section should describe only positive impacts so the decision looks well-reasoned.

• TrueTrue
• FalseFalse

Analyzing Architecture Risk

Risk analysis surfaces architectural deficiencies before they cause failures. The chapter offers a quantitative 1–9 risk matrix that turns subjective opinion into measurable scores, plus "risk storming," a collaborative exercise that brings multiple perspectives to bear on vulnerabilities across dimensions like availability, scalability, security, and performance.

The Risk Matrix (1–9 Scale)

Risk = Impact (1–3) × Likelihood (1–3), producing a numeric score from 1 to 9. Scores of 1–2 are low, 3–4 medium, 6–9 high. Multiplication removes much of the subjectivity from "low/medium/high" arguments.

Risk Direction Indicators

Beyond static ratings, annotate whether a risk is improving (+), steady, or worsening (−) over time. Leadership needs to see trends, not just snapshots — a risk holding at 6 is very different from a risk worsening from 3 to 6.

Risk Storming

A facilitated three-phase activity where architects, senior developers, and tech leads rate risks on an architecture diagram across dimensions like unproven tech, performance, scalability, availability, data loss, single points of failure, and security.

Identification Phase

Participants rate risks in isolation using the matrix and sticky notes before any discussion happens. The isolation is deliberate: it prevents groupthink and ensures diverse perspectives surface.

Consensus Phase

Participants reconvene to compare ratings. Where significant disagreement exists (one rates a 6 and another a 3), discussion clarifies assumptions until alignment is reached. The disagreements are where the learning happens.

Mitigation Phase

The group develops concrete strategies to reduce agreed-upon risks. The output is actionable architecture changes — circuit breakers, redundancy, caching — not just a list of worries.

Risk at the Quantum Level

Risk is evaluated per architecture quantum and per characteristic, not across the whole system. Different quanta typically have different risk profiles, just as they have different characteristics (Ch. 7).

Risk Matrix

3×3 grid mapping likelihood vs impact with multiplied score (1–9).

Risk Storming

Three-phase collaborative risk-identification activity.

Architecture Quantum

Unit at which risk is assessed.

Impact

Severity if a risk materializes (1–3).

Likelihood

How likely the risk is to occur (1–3).

Risk Direction

Visual marker showing whether a risk is trending better or worse.

Identification Phase

Opening, non-collaborative step of risk storming.

Consensus Phase

Group-alignment phase reconciling individual ratings.

Multiple choice

A risk has Impact = 3 (severe) and Likelihood = 2 (medium). What is its score on the risk matrix and how is it classified?

• A5 — medium
• B6 — high
• C3 — medium
• D9 — high

Multiple choice

Why does the identification phase of risk storming require participants to rate risks in isolation before discussion?

• ATo save time during the meeting.
• BTo prevent groupthink and ensure diverse independent perspectives surface.
• CBecause the matrix only works on individual scores.
• DBecause consensus is impossible otherwise.

Spot the issue

A team produces a risk report listing 30 risks as static "high" / "medium" / "low" labels with no indication of whether anything is getting better or worse. The director asks "are we improving?" and no one can answer. What's missing?

• ARisk direction indicators showing trend over time.
• BA bigger risk matrix.
• CMore participants in the rating session.
• DNothing — direction can be inferred.

True / False

Risk analysis in modern distributed systems should treat the whole system as the unit of analysis, not individual architecture quanta.

• TrueTrue
• FalseFalse

Diagramming and Presenting Architecture

Diagrams and presentations are the architect's primary communication medium. The chapter surveys the dominant diagramming standards (UML, C4, ArchiMate) and presentation patterns including the Takahashi/Lessig minimal-slide style, deliberate transitions, and incremental reveals.

Diagramming Standards

UML today is mostly reduced to class and sequence diagrams. C4 (Context, Container, Component, Code) was designed by Simon Brown and works well for monoliths. ArchiMate is a lightweight open-source enterprise modeling language scoped to be "as small as possible."

Representational Consistency

Maintain visual continuity when zooming in or switching views: the same component should look the same across diagrams, and transitions between abstraction levels should be explicit. The audience never loses orientation.

Line Semantics

A simple convention worth standardizing: solid lines = synchronous, dotted lines = asynchronous. Consistent line usage removes a whole class of ambiguity from architecture diagrams.

Irrational Artifact Attachment

The emotional overinvestment architects develop in particular diagrams. Treat diagrams as disposable artifacts; the team's understanding matters more than any one drawing's permanence.

Takahashi Method

Masayoshi Takahashi's minimalist presentation style: many slides, each containing only one or two very large words. Slides advance rapidly; the speaker carries the content. Lessig Method (Lawrence Lessig) is a close variant.

Bullet-Riddled Corpse Anti-Pattern

Slides crammed with bullet-point text. The audience reads ahead of the speaker; engagement dies. The fix is minimal text plus incremental reveals — letting the speaker stay ahead.

Transitions and Incremental Reveals

Rather than dropping a complete diagram on screen, build it up piece by piece so the audience follows the architect's reasoning. Deliberate transitions between slides reinforce narrative flow.

UML (Unified Modeling Language)

Standard graphical modeling language; class and sequence diagrams remain most-used.

C4 Model

Simon Brown's hierarchical Context/Container/Component/Code approach.

ArchiMate

Open-source enterprise architecture modeling language.

Takahashi Method

Presentation style with many short slides showing one or two large words.

Lessig Method

Lawrence Lessig's variant of tight slide/speech synchronization.

Incremental Build

A slide revealed progressively rather than all at once.

Transitions

Deliberate pacing devices between slides.

Bullet-Riddled Corpse

Anti-pattern slide overcrowded with bullets.

Representational Consistency

Keeping elements visually consistent across diagrams.

Multiple choice

According to the line-semantics convention, which is correct?

• ASolid lines = asynchronous, dotted lines = synchronous.
• BSolid lines = synchronous, dotted lines = asynchronous.
• CLine style is purely decorative.
• DDotted lines mean "deprecated."

Multiple choice

Which presentation anti-pattern does the Takahashi Method most directly counter?

• ABullet-Riddled Corpse — slides crammed with bullet text.
• BArchitecture Sinkhole — slides that just pass through.
• CFrozen Caveman — slides anchored on past decisions.
• DEmail-Driven Architecture — slides sent only by email.

Spot the issue

An architect presents a final architecture by dropping a single complex diagram on screen and talking through every box and arrow for ten minutes. Audience attention dies after two minutes. What technique would help most?

• ABigger fonts.
• BIncremental/building reveals — build the diagram up piece by piece so the audience follows the reasoning rather than scanning ahead.
• CRemoving all arrows.
• DUsing ArchiMate instead of C4.

True / False

Architects should treat their diagrams as permanent artifacts that must be preserved across the system's lifetime.

• TrueTrue
• FalseFalse

Making Teams Effective

An architect's job extends beyond producing diagrams — they must guide development teams to implement the architecture. The way team boundaries are set is the lever that determines success: three personality types (control freak, armchair, effective), calibration factors, warning signs, and the use of checklists.

Three Architect Personalities

Control freak sets boundaries too tight, micromanages, demotivates. Armchair is disconnected from implementation, sets boundaries too loose, forces developers to become accidental architects. Effective sets just-right boundaries and stays engaged.

Team Boundaries as the Lever

Architects shape outcomes by drawing the constraints around what the team may decide. Too tight = stifled creativity; too loose = confusion and lost velocity. The whole art is calibration.

Control Calibration Factors

The right level of control depends on team familiarity, team size, team experience, project complexity, and project duration. Experienced, smaller, tighter teams need less control; the inverse needs more.

Process Loss (Brooks's Law)

Adding people to a team paradoxically reduces effective output past a point — coordination overhead, merge conflicts, and communication costs grow non-linearly. More people doesn't mean more delivery.

Pluralistic Ignorance

Team members publicly agree with a decision they privately reject because they assume everyone else understands something they don't. Example: a team agrees to use messaging between services even though one member knows a firewall makes it pointless.

Diffusion of Responsibility

In larger teams, individuals feel less personally accountable. Tasks fall through cracks, roles blur. Closely linked to process loss and pluralistic ignorance — together they're the warning-sign trio.

Checklists

Three high-value checklists: Developer Code Completion (definition of done), Unit and Functional Testing (edge cases, non-automated scenarios), Software Release. Effective checklists are short, focused on error-prone areas, and exclude purely procedural items.

Control Freak Architect

Personality type with overly tight boundaries.

Armchair Architect

Personality type with overly loose boundaries; disengaged.

Effective Architect

Personality type with calibrated boundaries.

Process Loss

Productivity decay from coordination overhead as team size grows.

Pluralistic Ignorance

Public endorsement of a privately rejected position.

Diffusion of Responsibility

Reduced individual accountability in larger teams.

Hawthorne Effect

Behavior improves when people know they're being observed.

Definition of Done

Concrete criteria for considering code finished.

Multiple choice

A team agrees in a meeting to introduce a messaging broker between two services even though one engineer privately believes the firewall makes it impractical and several others suspect the same. Which dynamic is this?

• ADiffusion of responsibility
• BPluralistic ignorance
• CProcess loss
• DBrooks's Law

Multiple choice

Which architect personality sets team boundaries that are too loose, forcing developers to make accidental architecture decisions?

• AControl freak
• BEffective
• CArmchair
• DFrozen caveman

Spot the issue

A team's project is behind schedule, so leadership adds five more developers. A month later velocity has *decreased*. What principle explains this?

• APluralistic ignorance.
• BProcess loss / Brooks's Law — adding people to a late project past a point increases coordination overhead faster than throughput.
• CThe Hawthorne effect.
• DConway's Law.

True / False

A good code-completion checklist should be exhaustive, listing every step a developer takes.

• TrueTrue
• FalseFalse

Negotiation and Leadership Skills

Architects negotiate constantly — with business stakeholders, fellow architects, and developers — and lead teams without formal authority. The chapter offers concrete techniques for each context, introduces the 4 C's of architecture, and frames the architect as simultaneously pragmatic and visionary.

The 4 C's of Architecture

Communication, Collaboration, Clarity, and Conciseness — the core soft-skill competencies that make architects effective at influencing decisions across stakeholders, peers, and teams.

Negotiating with Business Stakeholders

Translate "-ility" demands into cost and time. When a stakeholder insists on "five nines" (99.999%) availability, probe whether "three nines" (99.9%) actually satisfies the underlying business need — drastically cheaper for nearly the same value.

Divide-and-Conquer Rule

Break broad architecture characteristics into measurable sub-concerns. Not "performance" but response time (e.g., 50 ms), throughput (e.g., 1000 req/sec), or resource utilization. Decomposed concerns are negotiable; vague characteristics aren't.

Negotiating with Other Architects

"Demonstration defeats discussion" — a working proof of concept beats hours of debate. Stay calm; avoid escalating arguments; let evidence win. Architects who lose arguments to data lose well.

Negotiating with Developers

State the justification before the decision, because once developers disagree they cognitively disengage and stop processing further arguments. Where possible, guide dissenters to self-discover the solution rather than imposing it.

Pragmatic Yet Visionary

Architects must hold strategic long-term vision *and* day-to-day pragmatism in tension. Pure vision gets dismissed as impractical; pure pragmatism produces no leadership. The job sits at the intersection.

Leading Without Formal Authority

Architects lead without org-chart authority, so credibility comes from demonstrated competence, integration with the development team, and modeling the behavior they expect. Title alone earns nothing.

The 4 C's

Communication, Collaboration, Clarity, Conciseness.

Divide-and-Conquer Rule

Decomposing broad characteristics into specific measurable concerns.

Demonstration Defeats Discussion

A working artifact wins arguments faster than rhetoric.

Pragmatic Yet Visionary

The dual stance the architect must occupy.

Cognitive Disengagement

Phenomenon where, once someone disagrees, they stop processing further arguments.

Five Nines / Three Nines

Shorthand availability targets (99.999% / 99.9%).

Facilitation

Guiding a group toward a decision without imposing one.

Negotiation

Reconciling competing concerns to produce a decision everyone can live with.

Multiple choice

A stakeholder demands five-nines (99.999%) availability for an internal HR tool used by 50 employees during business hours. What's the negotiation technique the book recommends?

• APromise five-nines and figure out the cost later.
• BProbe whether three-nines (99.9%) actually meets the underlying business need; five-nines costs orders of magnitude more for marginal real value here.
• CRefuse the requirement.
• DDecompose nothing; the stakeholder is always right.

Multiple choice

Why does the book recommend stating the justification before the decision when talking to developers?

• AJustifications make decisions more defensible in code review.
• BDevelopers who disagree cognitively disengage, so the justification must land first while they're still listening.
• CIt's a regulatory requirement.
• DIt makes the architect sound smarter.

Spot the issue

Two architects spend three hours debating whether a new service should be synchronous or asynchronous, with no resolution. One of them realizes they can build a small proof of concept in an afternoon. What principle should they invoke?

• ADemonstration defeats discussion — a working POC will settle the debate faster than more arguing.
• BDivide-and-conquer rule.
• CThe 4 C's.
• DFive nines.

True / False

Architects with the title "Chief Architect" automatically have enough formal authority to direct development teams without needing to build credibility.

• TrueTrue
• FalseFalse

Developing a Career Path

An architect's career is sustained by deliberate, ongoing breadth-building, not by deepening expertise in any single technology. The chapter codifies the 20-Minute Rule for daily learning, restates the laws of software architecture, advocates breadth over depth, and offers the personal Technology Radar.

Breadth Over Depth

Architects sacrifice some hard-won technical depth to widen their portfolio across frameworks, languages, and platforms. Matching capabilities to business constraints requires broad knowledge; deep specialization is the developer's path, not the architect's.

The 20-Minute Rule

Spend at least 20 minutes every day learning something new or deepening a topic relevant to architecture. Sustained over months, this is what keeps technical breadth from decaying. Skip it for weeks and the breadth erodes.

First Law of the 20-Minute Rule

Do it first thing in the morning, right after coffee/tea and *before* checking email. Plans to do it at lunch or after work almost always fail because the day eats the time. Timing is the rule.

First Law of Software Architecture

"Everything in software architecture is a trade-off." If you think you've found something that isn't, you haven't identified it yet. This is why architecture is hard and can't be Googled — and why breadth matters more than recipes.

Second Law of Software Architecture

"Why is more important than how." Architects justify decisions; they don't just describe them. The First and Second Laws frame the entire book.

Personal Technology Radar

Adapted from ThoughtWorks; four rings — Adopt (current expertise), Trial (promising, worth investing in), Assess (worth watching), Hold (deliberately deprioritized). Maps career intent visually and keeps learning purposeful.

Continuous Learning Imperative

Software professionals discard more learned detail in a lifetime than perhaps any other profession. Staying employable as an architect requires actively curating learning sources (InfoQ, DZone, ThoughtWorks Tech Radar, peer recommendations).

20-Minute Rule

Daily 20-minute investment in learning to sustain architect-level breadth.

First Law of the 20-Minute Rule

Do it first thing in the morning, before email.

First Law of Software Architecture

Everything is a trade-off.

Second Law of Software Architecture

Why beats how.

Technology Radar

Four-ring instrument (Adopt / Trial / Assess / Hold) for tracking technologies.

Breadth (Technical)

Wide cross-domain knowledge prioritized over deep specialization.

Depth (Technical)

Deep expertise in a narrow area, appropriate for developers.

Personal Resource Stockpile

Curated set of feeds and communities an architect consults.

Multiple choice

When does the book recommend doing the 20-minute learning block, and why?

• AAt lunch — energy is highest mid-day.
• BAfter work — fewest interruptions.
• CFirst thing in the morning before checking email, because the day reliably eats time slotted later.
• DOn weekends only.

Multiple choice

On a personal Technology Radar, which ring marks a technology you have deliberately decided not to invest in?

• AAdopt
• BTrial
• CAssess
• DHold

Spot the issue

A senior developer wants to become an architect and plans to "go deeper" in their favorite language and framework over the next two years to qualify. What's the strategic problem?

• AArchitects need breadth across many technologies, not deeper specialization in one — the plan moves in the wrong direction.
• BTwo years isn't enough.
• CThe developer should learn ArchiMate instead.
• DNothing — deepening expertise is the right path.

True / False

The First Law of Software Architecture says trade-offs always exist, even when not initially visible.

• TrueTrue
• FalseFalse