Redr · Study Guide
Software Architecture - The Hard Parts
Modern Trade-Off Analyses for Distributed Architectures
Neal Ford, Mark Richards, Pramod Sadalage & Zhamak Dehghani
Unofficial AI-assisted study guide. Not affiliated with or endorsed by the author or publisher. For educational use — supplements, not replaces, the original work.
Contents
- 01What Happens When There Are No "Best Practices"?
- 02Discerning Coupling in Software Architecture
- 03Architectural Modularity
- 04Architectural Decomposition
- 05Component-Based Decomposition Patterns
- 06Pulling Apart Operational Data
- 07Service Granularity
- 08Reuse Patterns
- 09Data Ownership and Distributed Transactions
- 10Distributed Data Access
- 11Managing Distributed Workflows
- 12Transactional Sagas
- 13Contracts
- 14Managing Analytical Data
- 15Build Your Own Trade-Off Analysis
- Part 01 · Pulling Things Apart01What Happens When There Are No "Best Practices"?02Discerning Coupling in Software Architecture03Architectural Modularity04Architectural Decomposition05Component-Based Decomposition Patterns06Pulling Apart Operational Data07Service Granularity08Reuse Patterns
- Part 02 · Putting Things Back Together09Data Ownership and Distributed Transactions10Distributed Data Access11Managing Distributed Workflows12Transactional Sagas13Contracts14Managing Analytical Data15Build Your Own Trade-Off Analysis
Part 01
Pulling Things Apart
Ch. 1–8
What Happens When There Are No "Best Practices"?
Architects rarely face problems with off-the-shelf solutions; their work is novel, context-bound trade-offs that resist universal best practices. The chapter frames good architecture as choosing the "least worst" combination of forces and introduces the analytical scaffolding — ADRs, fitness functions, and the Sysops Squad case study — used throughout the book.
The Hard Parts Premise
Architectural problems are unique because organizational context is unique. Generic best-practice advice fails, so trade-off analysis becomes the timeless skill — the work of choosing the "least worst" option rather than the optimal one.
Data as a First-Class Architectural Concern
Data flow, ownership, and consistency drive most decomposition decisions. Treating data as an implementation detail produces architectures that look clean on a diagram but seize at the database boundary.
Architectural Decision Records
ADRs are lightweight documents that capture each significant decision in three sections — Context, Decision, and Consequences. They make trade-offs explicit and durable so future architects know not just *what* was decided but *why* and at what cost.
Architecture Fitness Functions
A fitness function is any automated assessment that scores an architectural characteristic — modularity, layering, performance — like a unit test for the design. They turn intent into guardrails that resist erosion as the codebase changes.
The Sysops Squad Saga
The book's running case study is a failing call-center ticketing system with experts who arrive late, miss calls, and lose tickets. Architects Addison and Austen apply each chapter's pattern to this concrete scenario.
Architecture vs. Design Distinction
The book draws a deliberately simple line: architecture is the structural decisions that are hard to change; design is the implementation choices that are easier to revise. The book is about the hard-to-change category.
- ADR
- A short, versioned record of one architectural decision with context, choice, and consequences.
- Fitness function
- An automated test that scores how well the system meets a defined architectural characteristic.
- Architecture characteristic
- A non-domain quality the system must exhibit (scalability, performance, security) — sometimes called an "-ility."
- Trade-off analysis
- Structured comparison of options where every gain in one dimension costs something elsewhere.
- Sysops Squad
- The book's hypothetical ticketing company used as a running case study.
- Bounded context
- A DDD boundary inside which a single model is consistent; the natural seam for service extraction.
- Best practice (pejorative)
- A prescriptive rule the book rejects in favor of context-aware decision-making.
Multiple choice
The book argues that the timeless skill of an architect is not memorizing best practices but rather:
Multiple choice
What three sections does an Architectural Decision Record (ADR) capture?
True / False
A fitness function is a one-time checklist used during initial architectural review.
Spot the issue
A team treats database schema as an "implementation detail" to be solved after services are carved out. What is the main risk?
Discerning Coupling in Software Architecture
This chapter establishes the vocabulary used for the rest of the book, redefining the **architecture quantum** and splitting coupling into static (how services are wired) and dynamic (how they call each other) forms. It then decomposes dynamic coupling along three axes — communication, consistency, and coordination — that drive most distributed trade-offs.
Architecture Quantum
An architecture quantum is an independently deployable artifact with high functional cohesion, high static coupling, and synchronous dynamic coupling. Counting quanta tells you the real number of independent deployment units, regardless of how many "services" a diagram shows.
Static vs. Dynamic Coupling
Static coupling is how services are wired together — shared databases, contracts, frameworks, operating systems — visible in a topology diagram. Dynamic coupling is how services call each other at runtime to satisfy a workflow, visible only by tracing requests.
Three Dimensions of Dynamic Coupling
Dynamic coupling resolves into three axes: Communication (synchronous vs. asynchronous), Consistency (atomic vs. eventual), and Coordination (orchestration vs. choreography). Every distributed trade-off in the rest of the book is a point in this 3-D space.
Synchronous Calls Bind Quanta Together
Two services connected by a required synchronous call cannot be separate quanta because they fail and scale together. Async messaging breaks this bond and is the primary lever for splitting a system into multiple quanta.
Functional Cohesion Inside a Quantum
A quantum's parts must serve the same purpose — conceptually equivalent to a bounded context. Cohesion is what keeps the quantum from devolving into a distributed monolith hiding behind a service boundary.
Coupling Points Become Bottlenecks
A shared dependency — most often a shared database — binds every service that touches it. Scalability, elasticity, and availability decisions are then governed by the weakest shared dependency, not by any individual service.
- Architecture quantum
- Independently deployable artifact with high cohesion, high static coupling, and synchronous dynamic coupling.
- Static coupling
- Structural/operational dependencies needed to bootstrap a service (DB, contracts, frameworks).
- Dynamic coupling
- Runtime communication dependencies between services during a workflow.
- Functional cohesion
- Degree to which elements inside a quantum belong together because they serve one purpose.
- Synchronous communication
- Caller blocks waiting for callee's response; tightens coupling and shares failure modes.
- Asynchronous communication
- Caller fires-and-continues, usually via a broker; reduces temporal coupling.
- Orchestration
- Workflow style with a dedicated coordinator driving participants.
- Choreography
- Workflow style with no coordinator; participants react to events.
Multiple choice
Which three properties define an architecture quantum?
Multiple choice
Dynamic coupling resolves into three axes. Which is the correct trio?
Spot the issue
Two services are deployed as separate artifacts but communicate over a required synchronous REST call for every customer request. The team claims this is "two quanta." What's the real situation?
Multiple choice
A shared relational database is the static-coupling point for eight services. Scalability decisions for the system are governed by:
Architectural Modularity
Decomposition only pays off when justified by a concrete driver — agility, scalability/elasticity, or availability/fault tolerance. The chapter enumerates these drivers and shows how each maps to specific business pressures, then turns the drivers into a stakeholder-ready business case in the Sysops Squad saga.
Modularity Drivers Must Be Explicit
Don't decompose because microservices are trendy. Identify a measurable driver — agility, scale, or availability — first; otherwise distribution adds cost without benefit and produces a "distributed monolith."
The Agility Bundle
Agility combines three sub-drivers: maintainability (ease of change), testability (speed and completeness of verification), and deployability (frequency and safety of release). Together they're often called *speed-to-market*.
Scalability vs. Elasticity
Scalability is the ability to handle growing load by adding resources over time. Elasticity is the stricter ability to expand and contract capacity *suddenly* for bursty workloads — only some modules need it, which is itself a decomposition driver.
Availability and Fault Tolerance
Isolating capabilities limits failure blast radius. A failing module no longer takes the whole system down — *provided* runtime coupling is also reduced, since synchronous calls re-create the failure dependency you tried to remove.
Communication Erodes Modularity Gains
Every inter-service call partially undoes the benefits of decomposition. The book recommends asynchronous communication wherever possible to preserve the modularity wins decomposition was supposed to deliver.
Business Case First, Architecture Second
The Sysops Squad arc shows architects converting drivers into a written business case for executives funding the migration. Architecture work that can't be justified to stakeholders is unlikely to survive contact with delivery pressure.
- Modularity driver
- A specific business or operational reason that justifies the cost of distributing a system.
- Maintainability
- How easily the system absorbs change over time.
- Testability
- How completely and quickly changes can be verified.
- Deployability
- How safely and frequently the system can be released.
- Scalability
- Ability to handle increased load by adding resources.
- Elasticity
- Ability to handle sudden bursts of load through rapid expansion and contraction.
- Availability
- Probability the system is up and serving requests.
- Fault tolerance
- Ability of the system to keep functioning when components fail.
Multiple choice
"Agility" as a modularity driver bundles which three sub-drivers?
Multiple choice
What distinguishes elasticity from scalability?
Spot the issue
A team decomposes a monolith into microservices because "microservices give better availability." All services still call each other synchronously over REST for every request. What's the main flaw?
True / False
The Sysops Squad arc demonstrates that architects should convert modularity drivers into a written business case for stakeholders.
Architectural Decomposition
Once you've decided to decompose, the question is *can* this codebase actually be pulled apart. The chapter introduces structural metrics (afferent/efferent coupling, abstractness, instability, distance from the main sequence) and presents two strategies: **component-based decomposition** for codebases with discernible structure and **tactical forking** for big balls of mud.
Afferent and Efferent Coupling
Afferent coupling (Ca) counts incoming dependencies — how many components rely on this one. Efferent coupling (Ce) counts outgoing dependencies — how many components this one relies on. High Ca means change is risky; high Ce means the component is fragile.
Abstractness and Instability
Abstractness (A) = abstract types / total types — how "idea-like" the component is. Instability (I) = Ce / (Ce + Ca) — how exposed it is to outside change. The two metrics together describe a component's structural character.
Distance from the Main Sequence
Robert Martin's metric D = |A + I − 1| measures deviation from the healthy line where abstractness and stability balance. Large D lands you in the zone of pain (concrete + stable, hard to change) or the zone of uselessness (abstract + unstable, abstractions nobody uses).
Component-Based Decomposition
An incremental, refactoring-driven approach: identify components inside the monolith, harden their boundaries, and gradually externalize them as services. Preferred when components are already visible in the namespace structure.
Tactical Forking
Fausto De La Torre's strategy: clone the entire monolith per target team, then have each team delete what they don't own, sculpting their service from the copy. Preferred when the codebase is a big ball of mud and extraction would cost more than deletion.
Choosing the Approach
Component-based when seams exist; tactical forking when they don't. The trade-off is the deletion discipline and short-term redundancy of forking versus the longer timeline and extraction discipline of component-based.
- Afferent coupling (Ca)
- Count of incoming dependencies on a component.
- Efferent coupling (Ce)
- Count of outgoing dependencies from a component.
- Abstractness (A)
- Proportion of abstract types vs. total types in a component.
- Instability (I)
- Ce / (Ce + Ca); susceptibility to change from external dependencies.
- Main sequence
- The ideal line where A + I = 1 (stable code is abstract, unstable code is concrete).
- Zone of pain
- Concrete + stable — depended on by many, painful to change.
- Zone of uselessness
- Abstract + unstable — heavy abstractions nothing depends on.
- Tactical forking
- Cloning and pruning the monolith to carve services from copies.
- Big ball of mud
- A codebase with no discernible structure; the trigger for tactical forking.
Multiple choice
A component has Ce = 8 and Ca = 2. According to Robert Martin's metrics, this component is:
Multiple choice
A concrete component with very high afferent coupling and zero abstractness lands in which zone?
Spot the issue
The codebase is a true big ball of mud — no namespaces map to recognizable domains, classes reference each other freely. The team starts a 12-month component-based extraction. What's the main risk?
Multiple choice
What does tactical forking entail?
Component-Based Decomposition Patterns
Once you've chosen the component-based path, this chapter walks through six patterns that reshape a modular monolith into well-defined components ready to become services. Architects iteratively identify, size, flatten, group, and govern components — using fitness functions to enforce decisions and avoid sliding back.
Identify and Size Components
Detect components disproportionately large or small relative to the codebase average. Target sizes within roughly 1–2 standard deviations of the mean, using statement counts as a proxy for complexity.
Gather Common Domain Components
Consolidate duplicated business logic — not infrastructure — scattered across the codebase into a single shared domain component. Reduces accidental drift and creates a clear future service candidate.
Flatten Components
Ensure components live only as leaf nodes in namespace hierarchies. Move orphaned classes out of root or intermediate namespaces so future service boundaries are unambiguous.
Determine Component Dependencies
Map afferent and efferent coupling between components to gauge migration feasibility. High coupling is the single biggest obstacle to decomposition and signals where the migration will hurt.
Create Component Domains and Domain Services
Logically group related components into coarse-grained domains using namespace conventions like `app.domain.subdomain.component`, then promote the groupings into separately deployed domain services. Coarse first, fine later.
Fitness Functions Guard Each Pattern
Each pattern is enforced by automated fitness functions — "no source in root namespace," "component statement count under threshold." Without automation, the patterns erode as soon as delivery pressure rises.
- Component
- An architectural building block of related classes, usually a namespace or package.
- Statement counting
- Heuristic that uses source statements as a rough complexity proxy.
- Orphaned class
- A source file living in a root or subdomain namespace rather than a leaf component.
- Leaf node component
- A component at the end of a namespace path with no nested children.
- Domain service
- A coarse-grained, separately deployable unit owning one business domain.
- Total coupling
- Sum of afferent + efferent coupling for a component.
- Refactoring-driven extraction
- Incremental component-based path (vs. tactical forking).
Multiple choice
The "flatten components" pattern requires components to live only as:
Multiple choice
What does the book recommend grouping into a "common domain component"?
Spot the issue
A team completes a beautiful component-based decomposition. Six months later, source files have crept back into root namespaces and one component's statement count has doubled. What was missing?
True / False
The book recommends sizing components within roughly 1–2 standard deviations of the mean, using statement counts as a complexity proxy.
Pulling Apart Operational Data
Once components and services are identified, architects must decide whether to split the shared database that backs them. The chapter introduces **data disintegrators** (forces pushing data apart) and **data integrators** (forces holding it together), plus a five-step process for safely splitting a monolithic schema.
Data Disintegrators
Forces that justify splitting a database: change control, connection management, scalability, fault tolerance, architectural-quantum expansion, and database-type optimization. Each one is a distinct argument for a different stakeholder.
Data Integrators
Forces that justify keeping data together: data relationships (foreign keys, triggers, views, stored procedures) and database transactions (ACID). Splitting always sacrifices at least one of these.
Change Control as a Driver
Every schema change in a shared database ripples to every dependent service. Splitting localizes breaking changes to a single owner and lets the rest of the system evolve at its own pace.
Connection Management
A shared database has a finite pool of connections. Splitting allows per-service connection quotas and prevents one chatty service from starving the others.
Polyglot Persistence
Different data shapes — key-value, document, graph, time-series, relational — belong in different engines. A single relational database optimizes for none and locks the architecture out of better-fitting storage technologies.
Five-Step Decomposition Process
(1) Analyze the database and create data domains, (2) assign tables to domains, (3) separate connections per domain, (4) move schemas to separate database servers, (5) switch over to independent servers. The order minimizes downtime and rollback risk.
- Data disintegrator
- A driver justifying splitting data across separate databases or schemas.
- Data integrator
- A driver justifying keeping data physically or logically unified.
- Data domain
- A logical grouping of tables aligned to a bounded context and owned by one service.
- Connection quota
- The maximum number of DB connections a service may consume.
- Referential integrity
- Cross-table consistency enforced by foreign keys.
- Schema separation
- Splitting one physical schema into multiple, possibly across servers.
- Polyglot persistence
- Using multiple database technologies in one system, each fit to a data pattern.
Multiple choice
Which of the following is a *data integrator* — a force that argues for keeping data together?
Multiple choice
What is the correct order of the five-step database decomposition process?
Spot the issue
A team keeps a shared monolithic relational database for 20 microservices, arguing the FK constraints are too valuable to lose. What is the most likely operational pain?
Multiple choice
What is "polyglot persistence" and why does the book consider it a disintegrator?
Service Granularity
"How big should a service be?" is answered not by rules of thumb but by weighing **granularity disintegrators** (forces favoring smaller services) against **granularity integrators** (forces favoring larger ones). The chapter defines six disintegrators and four integrators that architects balance to find the right service size for their context.
Granularity vs. Modularity
Modularity is *how* code is partitioned — logical structure. Granularity is *how much* code lives in each deployable service. They are independent dimensions: a well-modularized codebase can still be poorly granular.
Service Scope and Function
Each service should "do one thing well." High functional cohesion within a single responsibility argues for a smaller service — but "one thing" is itself a trade-off line, not a hard rule.
Code Volatility and Fault Tolerance
Code volatility — when part of a component changes far more often than the rest — argues for splitting to isolate test and deployment blast radius. Fault tolerance similarly argues for splitting code prone to crashes or memory leaks.
Scalability, Security, and Extensibility
Splitting lets you scale just the hot path, apply tighter security controls to sensitive code, and add functionality without redeploying unrelated logic. Each is a distinct disintegrator stakeholders can recognize.
Database Transactions as Integrator
If operations require ACID semantics across multiple steps, keeping them in one service avoids fragile distributed transactions. Transaction boundaries are one of the strongest forces pulling services back together.
Workflow and Data Relationships as Integrators
Heavy inter-service chatter erodes performance and fault tolerance, and tight data relationships push services back together. Shared code is a weaker integrator — replication or libraries usually solve it without re-merging services.
- Service granularity
- The size of a service, typically measured by statement count and number of public interfaces.
- Granularity disintegrator
- A driver justifying breaking a service into smaller services.
- Granularity integrator
- A driver justifying consolidating multiple services into a larger one.
- Service consolidator
- An architect's act of merging services when integrator forces outweigh disintegrators.
- Code volatility
- Rate at which a piece of code changes relative to neighbors.
- Workflow coupling
- Coordination overhead and chattiness between collaborating services.
- Granularity trade-off analysis
- Explicit weighing of disintegrator vs. integrator forces for a candidate split.
Multiple choice
The book distinguishes modularity and granularity as:
Multiple choice
Which is a *granularity integrator* — a force pulling services back together?
Spot the issue
A team splits a single service into eight smaller services in pursuit of "one thing well." Now every business request triggers six synchronous inter-service calls. What's the main risk?
Multiple choice
Why does the book treat shared code as a *weaker* integrator force than transactions or workflow?
Reuse Patterns
Sharing code across services is harder than in a monolith because every reuse mechanism introduces coupling and rate-of-change conflicts. The chapter compares four patterns — **code replication**, **shared library**, **shared service**, and **sidecar/service mesh** — and lands on the core insight: "Reuse is derived via abstraction but operationalized by slow rate of change."
Code Replication
Copy-paste shared code into each service. Eliminates runtime coupling but requires discipline to keep copies in sync — best reserved for small, stable code unlikely to change.
Shared Library
Package shared code as a versioned dependency consumed at compile/build time. Strong compile-time safety, but creates dependency-management and versioning burdens; works best in single-language stacks with low-to-moderate change rates.
Shared Service
Extract shared functionality into its own runtime service called over the network. Easier to roll out changes and supports polyglot stacks, but sacrifices performance, scalability, and fault tolerance because every caller depends on it at runtime.
Sidecar Pattern and Service Mesh
The sidecar deploys cross-cutting concerns — logging, metrics, security, tracing — as a co-located process attached to each service. A network of sidecars under a control plane is the service mesh, the foundation of cross-cutting operational consistency.
Domain vs. Infrastructure Reuse
Domain reuse (validation, notifications, formatting) usually belongs in libraries or domain services. Infrastructure reuse (logging, auth, metrics, tracing) usually belongs in sidecars or the mesh — different problems demand different patterns.
Slow Rate of Change Is the Real Requirement
Reuse only works when the shared abstraction changes slowly relative to its consumers. Fast-changing shared code becomes a coordination bottleneck regardless of which reuse pattern wraps it.
- Code replication
- Reuse by duplication; each service owns its own copy.
- Shared library
- Compile-time reuse via a versioned binary artifact (JAR, DLL, package).
- Shared service
- Runtime reuse via a separately deployed service over the network.
- Sidecar
- A helper process deployed alongside a service to handle cross-cutting concerns.
- Service mesh
- Network of sidecars plus a control plane governing them.
- Cross-cutting concern
- Functionality (logging, auth, metrics) needed everywhere but core to nothing.
- Versioning strategy
- Rules for releasing, supporting, and deprecating shared library versions.
- Fine-grained library
- Many small, focused libraries rather than one "kitchen sink" — reduces change-coupling.
Multiple choice
The book's core insight about reuse is that reuse is derived via abstraction but operationalized by:
Multiple choice
A team needs consistent logging, metrics, and tracing across 30 polyglot microservices. Which reuse pattern is the best fit?
Spot the issue
A team extracts a popular "Validation" shared service called synchronously by 12 services on every request. What is the main runtime risk?
True / False
The book recommends a single, kitchen-sink shared library to maximize reuse across services.
Part 02
Putting Things Back Together
Ch. 9–15
Data Ownership and Distributed Transactions
Once the database is pulled apart, architects must decide which service owns which table. The chapter establishes that **the service that performs writes owns the data**, then walks through single, common, and joint ownership scenarios, four resolution techniques for joint ownership, and three patterns for eventual consistency.
Single, Common, and Joint Ownership
Single ownership: only one service writes the table — the easy case. Common ownership: most services need to write (e.g., an audit log) — fix by creating a dedicated owner service that consumes writes asynchronously. Joint ownership: a handful of services in one domain all write the same table — the hard case.
Table Split Technique
Split the shared table column-wise so each service owns the columns it actually writes, joining via foreign-key reference. Trades clean ownership for ongoing cross-service synchronization.
Data Domain Technique
Leave the table jointly owned inside a shared schema accessed by both services. Best performance and integrity, but widens the bounded context and weakens information hiding.
Delegate and Service Consolidation Techniques
Delegate: pick one service as sole writer; the other calls it. Simple ownership but synchronous coupling. Service consolidation: merge the joint owners into one service — eliminates the problem but sacrifices independent deployability.
Eventual Consistency Patterns
Background synchronization uses a separate sync process — longest consistency window. Orchestrated request-based uses an orchestrator with compensating transactions — favors consistency. Event-based uses publish/subscribe — shortest window, most decoupled, and the book's preferred default.
ACID vs. BASE
Single-database transactions give ACID guarantees (atomicity, consistency, isolation, durability). Distributed systems trade this for BASE (basically available, soft state, eventual consistency) — a fundamentally different correctness contract.
- Distributed transaction
- A single business request whose work spans multiple services and databases.
- Compensating transaction
- A business-level semantic undo issued when a later step fails.
- Dead letter queue (DLQ)
- A holding queue for messages that repeatedly fail processing.
- Data domain
- A schema of tables, triggers, and procedures belonging to one logical domain.
- Eventual consistency
- Replicas converge given enough time and no new updates.
- Bounded context
- A DDD boundary inside which one model is internally consistent.
- ACID
- Atomicity, Consistency, Isolation, Durability.
- BASE
- Basically Available, Soft state, Eventual consistency.
Multiple choice
What is the book's foundational rule for data ownership across services?
Multiple choice
An "audit log" table is written by nearly every service in the system. Which ownership scenario is this, and what is the book's fix?
Spot the issue
Two services in the same domain both need to write the Customer table frequently. The team picks the "delegate" technique, routing all of Service B's writes through Service A. What's the main risk?
Multiple choice
Among the three eventual-consistency patterns, which does the book identify as the preferred default with the shortest consistency window?
Distributed Data Access
Even with ownership settled, a service still frequently needs to *read* data owned by another service. The chapter presents four access patterns — **interservice communication**, **column schema replication**, **replicated caching**, and **data domain** — and rates each across coupling, fault tolerance, scalability, consistency, and currency.
Interservice Communication
The reading service makes a remote (REST/gRPC/messaging) call to the owning service. Simple and always-fresh, but inherits network latency, security tax, and availability/scalability coupling.
Column Schema Replication
Columns owned by Service A are replicated into Service B's table so B can read them locally. Excellent read performance and fault tolerance, but raises hard governance problems — B can accidentally write data it doesn't own.
Replicated Caching
Each service holds an in-memory replica of the owning service's cache, kept in sync asynchronously via a distributed cache product (Hazelcast, Apache Ignite, Oracle Coherence). Reads are local and ownership is preserved, but startup latency and memory cost limit applicability.
Data Domain Pattern
Both services share a schema and read directly from the same tables. Strong consistency and no contract overhead, but explicitly widens the bounded context and creates schema-change coupling.
Trade-off Star Ratings
The book scores each pattern across five characteristics — service coupling, fault tolerance, scalability/throughput, data consistency, data currency. The point: no pattern wins everywhere; match the pattern to the constraint.
Data Volatility Drives Pattern Choice
Highly volatile data pushes you toward interservice communication or shared data domain. Static or slowly-changing data fits replicated caching or column schema replication. Volume and currency tolerance shape the rest.
- Service coupling
- Degree to which two services depend on each other's availability, location, or shape.
- Data currency
- Freshness of data relative to the system of record.
- Replicated cache
- Cache topology where every member holds a full copy, kept in sync peer-to-peer.
- Bounded context broadening
- Unintended boundary expansion when services share schemas or columns.
- Stamp coupling
- Passing more data through a contract than the recipient needs.
- Aggregation/reporting data
- Read-heavy, infrequently-updated data — canonical fit for column replication.
- Fault tolerance (in data access)
- Service's ability to keep functioning when the data owner is down.
Multiple choice
A reporting service needs read-heavy access to slowly-changing customer data owned by another service. Network latency and the owner's availability must not affect the reporting service. Which pattern is the best fit?
Multiple choice
The Replicated Caching pattern relies on:
Spot the issue
A team adopts the Data Domain pattern so two services can read each other's tables directly through a shared schema. They love the performance. What's the architectural cost they may be ignoring?
True / False
Highly volatile data is well served by replicated caching because changes propagate fast.
Managing Distributed Workflows
With data distributed, the next problem is how a multi-step business process traverses services. The chapter contrasts **orchestration** (a mediator coordinates) with **choreography** (services react to events) and analyzes their trade-offs in state, error handling, recoverability, and coupling. The opinion: workflow complexity, not dogma, drives the choice.
Orchestration
A dedicated orchestrator holds workflow state, calls each participant in order, and drives compensating actions on failure. One orchestrator per workflow is the recommended cardinality — easy to reason about, but a coupling and scaling target.
Choreography
No mediator; each service reacts to events or messages from upstream services. Lower coupling and higher fault tolerance, but the workflow's logic is smeared across the participants and harder to observe.
Front Controller Pattern
In choreography, the first service in the chain often absorbs partial orchestration duties — state, error handling. This edges the workflow back toward orchestration and adds semantic coupling to that "first" service.
Stamp Coupling for State
Workflow state can be embedded as a stamp inside every message passed between services so each step knows what came before. Avoids a central store but bloats contracts and hides dependencies.
Workflow Complexity Heuristic
As the number of steps, branches, and error paths grows, the orchestrator's benefit grows roughly linearly while choreography's complexity grows faster than linearly. Complex workflows favor orchestration; simple ones favor choreography.
Semantic vs. Implementation Coupling
Choreography reduces implementation coupling — services don't call each other directly — but can *increase* semantic coupling — services must agree on event meaning and ordering. Loose wiring doesn't mean loose understanding.
- Orchestration
- Mediator-driven workflow with centralized state and error handling.
- Choreography
- Peer-to-peer workflow where services react to events.
- Mediator/orchestrator
- The service that owns workflow state in an orchestrated saga.
- Front controller
- A service in a choreographed workflow that absorbs partial mediator duties.
- Stamp coupling
- Passing more fields than the immediate operation needs to carry context downstream.
- Workflow state
- Persisted "where are we" data — held by orchestrator, controller, stamp, or query.
- Compensating transaction
- Business-level reversal step when a workflow step fails.
Multiple choice
As workflow complexity (steps, branches, error paths) grows, the book says:
Multiple choice
In a choreographed workflow, the first service in the chain often absorbs partial mediator duties. What is this called, and what does it introduce?
Spot the issue
A team picks choreography over orchestration because "it's more decoupled." Six months later, every service must know the precise event ordering and field semantics of every other service. What kind of coupling is biting them?
Multiple choice
What is the book's recommended cardinality for orchestrators?
Transactional Sagas
This chapter combines three dimensions — **Communication** (sync/async), **Consistency** (atomic/eventual), and **Coordination** (orchestrated/choreographed) — into 2×2×2 = eight named saga patterns. Each is rated across coupling, complexity, responsiveness, and scalability. The names function as shared vocabulary for trade-off conversations, not as a menu of "best" picks.
Epic Saga (sync/atomic/orchestrated)
The pattern that tries to emulate a monolithic transaction across services. Very high coupling, low scalability, easy to reason about — the "we wish this still worked" pattern that motivates moving toward eventual consistency.
Phone Tag Saga (sync/atomic/choreographed)
No coordinator, but still atomic and synchronous. Services call each other in a chain and compensate backward on failure. High complexity for non-trivial workflows; suited to short happy paths with few error branches.
Fairy Tale Saga (sync/eventual/orchestrated)
Orchestrator coordinates calls and error handling, but participants commit their own local transactions. Very low complexity and the most common real-world microservices pattern — the saga most architects converge on.
Time Travel Saga (sync/eventual/choreographed)
No mediator; services pass control synchronously down a chain — a Chain of Responsibility / Pipes-and-Filters flow. Good when ordered hand-off is natural and rollback is rare.
Fantasy Fiction and Horror Story Sagas
Fantasy Fiction (async/atomic/orchestrated) tries to keep atomic consistency while going async; the authors warn it usually fails because async + atomic is largely contradictory. Horror Story (async/atomic/choreographed) is treated as an outright anti-pattern.
Parallel and Anthology Sagas
Parallel Saga (async/eventual/orchestrated) keeps a coordinator while letting branches run in parallel — high throughput with retained observability. Anthology Saga (async/eventual/choreographed) is pure event-driven choreography — loosest coupling, highest scalability, hardest to observe.
- Transactional saga
- A long-running business transaction implemented as a sequence of local transactions.
- Atomic consistency
- All steps appear to succeed or fail together from a business view.
- Eventual consistency
- Participants commit independently and the system converges later.
- Compensating transaction
- Business-level reversal step that semantically undoes a prior commit.
- State machine
- The authors' recommended modeling tool — explicit states, transitions, and compensations.
- Saga coordinator
- The component driving an orchestrated saga and deciding when to compensate.
- Choreographed saga
- A saga with no coordinator; services publish events and react to peers.
- Coupling/complexity star rating
- The book's per-pattern scorecard across four characteristics.
Multiple choice
The Epic Saga (sync/atomic/orchestrated) is best described as:
Multiple choice
Which saga does the book identify as the most common real-world microservices pattern?
Spot the issue
A team proposes async messaging plus *atomic* consistency plus choreography because they want "the best of all worlds." What does the book say?
Multiple choice
Which saga combination does the book describe as offering the loosest coupling and highest scalability — at the cost of being hardest to observe?
Contracts
Contracts are the format used by architectural parts to convey data and dependencies. The chapter explores the spectrum from **strict** (gRPC, XML Schema, JSON Schema) to **loose** (free-form JSON name-value pairs), arguing that contract choice is a primary lever for coupling — and that stamp coupling is the silent tax architects most often forget to pay.
Strict Contracts
Strict contracts enforce exact names, types, and ordering with zero ambiguity. They maximize contract fidelity but produce brittle integration: changes require lockstep versioning across producer and every consumer.
Loose Contracts
Loose contracts are name-value pairs in JSON/YAML with minimal specification. They maximize decoupling and evolvability at the cost of needing fitness functions to verify integrity at runtime instead of compile time.
Stamp Coupling
Two services share a composite data structure but each uses only a fragment of it. Over-passing data creates hidden dependencies — and at scale, the unused fields become a measurable bandwidth cost.
GraphQL and REST as Middle Ground
REST lets a service add resource fields without breaking existing consumers. GraphQL lets each consumer request only the fields it needs — directly mitigating stamp coupling without forcing strict schemas everywhere.
Consumer-Driven Contracts
CDC flips the contract authoring direction: consumers publish their expectations, which the producer verifies during build. Gives loose-contract decoupling with strict-contract safety.
Stamp Coupling Sometimes Pays
In sagas and orchestrated workflows, passing a rich envelope so each step reads its needed slice avoids an extra round trip. Useful stamp coupling is a deliberate trade-off, not an accident.
- Contract
- The format describing what data flows between architectural parts.
- Strict contract
- Schema-bound interface where every field, type, and order is enforced.
- Loose contract
- Minimally specified interface that tolerates additions and missing fields.
- Contract fidelity
- Confidence level that data adheres to the agreed shape.
- Stamp coupling
- Coupling arising from passing more data than the consumer uses.
- Semantic coupling
- Coupling rooted in business meaning, independent of contract format.
- Consumer-driven contract
- A contract authored by the consumer and verified by the producer.
- Bandwidth cost
- The serialization and network overhead of oversized payloads at scale.
Multiple choice
Which of the following is the main trade-off of using a *strict* contract (e.g., gRPC, XML Schema)?
Multiple choice
Stamp coupling is best defined as:
Spot the issue
A consumer team complains that the producer keeps breaking their integration. The producer team has no idea which fields the consumer actually uses. What pattern would best address this?
True / False
Stamp coupling is always an anti-pattern to be eliminated.
Managing Analytical Data
Operational and analytical data have different shapes, owners, and consumers. The chapter walks the evolution from **data warehouse** to **data lake** to **data mesh**, then applies the data mesh's **Data Product Quantum** to the Sysops Squad split — closing the operational portion of the saga.
Operational vs. Analytical Data Plane
Operational data runs the business in the moment (OLTP). Analytical data supports reporting, BI, and ML (OLAP). They have different SLAs, schemas, and ownership and can't be served well by the same store.
Data Warehouse Limits
Centralized, schema-on-write, ETL-heavy. Transformation at ingestion couples the warehouse to every source and becomes a bottleneck — technical partitioning fights the domain partitioning the rest of the architecture established.
Data Lake Limits
Schema-on-read defers transformation to consumers. The raw landing zone produces discoverability problems, PII and governance risk, and eventually a "data swamp" where no one knows what's reliable.
Data Mesh
Treats analytical data like microservices: domain-aligned, productized, served on a self-serve platform under federated computational governance. Reverses the centralization that warehouses and lakes assumed.
Data Product Quantum (DPQ)
The architectural quantum of data mesh: a self-contained unit bundling code (pipelines, APIs, policies), data, and metadata, deployed alongside its operational quantum. A DPQ is orthogonal coupling, not embedded coupling.
Federated Computational Governance
Global policies — privacy, lineage, quality — are encoded as automated checks, often sidecars, so domains stay autonomous without diverging. Governance becomes a platform feature instead of a committee.
- Data warehouse
- Centralized analytical store with schema-on-write ETL pipelines.
- Data lake
- Centralized raw store with schema-on-read processing pushed to consumers.
- Data mesh
- Decentralized, domain-oriented analytical architecture built on four principles.
- Domain ownership of data
- The producing team owns the analytical version end-to-end.
- Data as a product
- Data is designed, versioned, monitored, and SLA'd like a consumer product.
- Data Product Quantum (DPQ)
- Independently deployable unit bundling data, code, metadata, and policy.
- Federated computational governance
- Cross-team policies enforced automatically.
- Self-serve data infrastructure
- Reusable tooling that lets domains publish data products without bespoke pipelines.
Multiple choice
Which is the main limitation the book identifies with a centralized data warehouse?
Multiple choice
The four principles of data mesh include all of the following EXCEPT:
Multiple choice
What is a Data Product Quantum (DPQ)?
Spot the issue
A team builds a centralized data lake and lets each producing team dump raw data into it with no schema, lineage, or quality checks. Two years later nobody trusts the data. What's this called?
Build Your Own Trade-Off Analysis
Written in second person, this chapter steps back from specific patterns to teach a repeatable method: **find entangled dimensions**, **untangle them**, **model relevant scenarios**, and produce decisions you can explain to non-architects. It catalogs the analytic moves used throughout the book and warns against the traps that turn analysis into evangelism.
Find Entangled Dimensions, Then Untangle Them
Real architectural problems mix multiple forces — consistency + coupling + communication. Step one is naming each dimension; step two is analyzing them one at a time before recombining the verdict.
Analyze Coupling Points First
Coupling is the structural backbone of any trade-off. Identify static (build-time) and dynamic (runtime) coupling before reasoning about characteristics like scalability or fault tolerance — the coupling story constrains everything else.
Qualitative vs. Quantitative Analysis
Architects rarely have clean numerical data. Well-structured qualitative comparisons — pros/cons per dimension — usually beat false-precision metrics that imply more certainty than the data supports.
MECE Lists
Compare options that are Mutually Exclusive (no overlapping capability) and Collectively Exhaustive (no relevant alternative omitted). Prevents apples-to-oranges errors like comparing a queue to an ESB.
The Out-of-Context Trap
Generic recommendations — "use Kafka," "always cache" — fail because they ignore the specific domain, scale, and team context that produced the original recommendation. Strip the context and the advice becomes noise.
Bottom Line Over Overwhelming Evidence
Distill the matrix into a one-line recommendation a non-technical stakeholder can act on. Exhaustive proof paralyzes decisions; a clear bottom line is what makes architecture useful to the business.
Avoid Snake Oil and Evangelism
Resist resume-driven design and vendor hype. Every "best practice" carries a trade-off — the architect's job is to surface it, not sell it.
- Trade-off analysis
- Structured comparison of options across the dimensions that matter for a specific decision.
- Entangled dimensions
- Two or more architectural concerns whose effects are mixed and must be separated.
- Qualitative analysis
- Comparison via reasoned descriptions and tables rather than numerical scores.
- MECE
- Mutually Exclusive, Collectively Exhaustive — a list-construction discipline for comparable option sets.
- Out-of-context trap
- Applying a recommendation outside the situation that produced it.
- Scenario modeling
- A concrete business example used as a test harness for candidate designs.
- Bottom-line bias
- Preference for the smallest sufficient summary when communicating decisions.
- Snake oil / evangelism
- Promotion of a technology as universally applicable; the inverse of trade-off thinking.
Multiple choice
The book's repeatable method for trade-off analysis begins with which step?
Multiple choice
MECE list construction means:
Spot the issue
An architect copies a Kafka-based event-driven design from a famous tech blog into a 30-developer enterprise CRM project. The team struggles for months. What trap did they fall into?
True / False
The book recommends presenting stakeholders with overwhelming quantitative evidence rather than a one-line bottom-line recommendation.
Key Takeaways
Architecture is the stuff you can't Google; the timeless skill is trade-off analysis, not memorizing best practices.
Coupling has two faces — static (how services are wired) and dynamic (how they talk at runtime) — and the architectural quantum unifies them.
Don't decompose for fashion; decompose only when a concrete driver like agility, scalability, or fault tolerance justifies the distributed tax.
The service that writes the data owns the data — every distributed transaction pattern flows from that single rule.
Workflow choice (orchestration vs. choreography) and saga shape (sync/async × atomic/eventual × orchestrated/choreographed) define the eight transactional patterns architects pick between.
Contracts, sagas, and analytical data are levers on coupling; tightening one almost always loosens another, which is why a structured method beats any dogma.