The Hard Parts

1There are no best practices, only the least worst trade-offs

The opening chapter makes the book's bet explicit: if a practice were truly "best", everyone would apply it and the problem would be boring. The problems that remain are the ones without a general answer: "for architects, every problem is a snowflake" (ch. 1). So the skill to build is not picking the right pattern, it is weighing: "don't try to find the best design in software architecture; instead, strive for the least worst combination of trade-offs" (ch. 1).

Two tools carry that discipline through the book. ADRs (Architecture Decision Records: context, decision, consequences, so the "why" survives the people). And fitness functions: architecture rules turned into executable tests in the CI, that fail the build the moment a boundary is crossed.

// an architecture rule becomes a test (here ArchUnit, in Java)
noClasses().that().resideInAPackage("..domain..")
  .should().dependOnClassesThat().resideInAPackage("..web..");
// business code importing the controller → CI goes red, not a review to catch

The whole book then follows one fictional team, the Sysops Squad, whose aging ticket monolith freezes for hours and threatens the whole business line.

2The architecture quantum: your shared database betrays you

The book's measuring unit: an architecture quantum is "an independently deployable artifact with high functional cohesion, high static coupling, and synchronous dynamic coupling" (ch. 2). Concretely: the smallest piece of your system you can deploy alone. And the count is brutal: a monolith is one quantum, obviously, but so are twenty "microservices" sharing one database. If the schema changes and everyone must move together, you have one quantum with extra network bills.

Underneath sits the book's reading grid for runtime coupling, three dimensions with two values each: communication (synchronous or asynchronous), consistency (atomic or eventual), coordination (orchestrated or choreographed). Hold that thought: 2 × 2 × 2 returns in idea 7.

3Splitting the database is harder than splitting the code

"Breaking apart a database is hard—much harder, in fact, than breaking apart application functionality" (ch. 6). Code has imports you can list; data has foreign keys, views, triggers, and the awkward fact that it is the company's most precious asset. The book's argument to a skeptical DBA is numerical: a monolith with 200 database connections, redistributed across 50 services with their connection pools and minimum instances, asks for 1,000 to 1,700 connections for the same workload.

The method is five steps that never break production: group tables into data domains, move them into separate schemas, untangle the cross-domain connections, then (and only then) move schemas onto their own servers, and switch over. The slogan of the chapter: make the data follow the domains, not the technology.

4Granularity is an equilibrium, not a threshold

How small should a service be? The book refuses the question and replaces it with two opposing lists. Six reasons to split (disintegrators): single-purpose scope, code volatility, divergent scalability needs, fault isolation, security boundaries, planned extensibility. Four reasons to merge (integrators): database transactions, chatty workflows between the parts, heavily shared code, tightly related data.

The demonstration runs on one notification service: sending SMS, emails and postal letters looks cohesive, until you learn the letter templates change weekly while SMS code sleeps for six months (volatility says: split), and the system pushes 220,000 SMS a minute against one letter (scalability says: split). But five customer services chained in one workflow add up 1,500 ms of pure network latency (workflow says: merge). "The secret of arriving at the appropriate level of granularity for a service is achieving an equilibrium between these two opposing forces" (ch. 7). Bonus test: if the leftover service can only be named "Other Stuff Service", the split was wrong.

5Reuse is coupling wearing a nice suit

The most quotable law of the book: "reuse is derived via abstraction but operationalized by slow rate of change" (ch. 8). You can safely depend on an OS, a framework, JUnit: they are abstractions that change slowly and predictably. A shared internal Customer class changes every sprint; share it across services and every change ripples everywhere. That single sentence is the post-mortem of 2000s SOA and its dream of the one reusable enterprise Customer service, which the book calls out as an architectural disaster.

Four honest options are weighed: copy the code (fine for code that never changes), shared library (compile-time safety, versioning pain), shared service (good for volatile code, but a runtime risk for everyone), and sidecars for the operational plumbing (logging, monitoring, auth), which is the only place reuse is unconditionally cheap because it carries no domain logic.

6ACID does not survive distribution

The chapter every microservices team should read before the first incident: once a business transaction spans services, every letter of ACID quietly dies. No global rollback (each service commits its own part), no isolation (committed data is visible before the "transaction" finishes), no cross-service foreign keys. What you get instead is BASE: basic availability, soft state, eventual consistency.

Since there is no automatic rollback anymore, YOU have to write the undo, by hand, step by step, what we call a saga:

try {
  payment.charge()        // service 1: committed right away, no global rollback
  stock.reserve()         // service 2: fails here…
} catch {
  payment.refund()        // …you must COMPENSATE step 1 by hand (and if that fails?)
}

Three patterns deliver that "eventual": a background batch that reconciles (slow, and it tramples every bounded context, those self-contained business areas), an orchestrator that calls everyone while the user waits (consistent, but compensation can itself fail), or events on a durable broker (responsive and decoupled, but the error path ends in a dead letter queue, the queue of failed messages a human must handle). The book's running gag is borrowed from Gregor Hohpe's classic title: "Starbucks Does Not Use Two-Phase Commit". Neither should you.

7The eight sagas: naming your troubles

Cross the three runtime dimensions (sync/async × atomic/eventual × orchestrated/choreographed) and you get exactly eight possible transactional sagas. The book names each one after the kind of story it puts you in, and the names do real work in meetings.

The diagnosis behind the colors: distributed atomicity is the expensive column. "Distributed transactions present a host of difficulties and thus are best avoided if possible" (ch. 12). The Horror Story deserves its name because it is well-intentioned: an architect speeds up a slow Epic Saga with async messaging and no coordinator, while keeping atomicity, and lands on the worst complexity of the table.

8Build your own analysis, and flee the evangelists

The last chapter turns the whole book into a reusable method in three steps: find which parts are entangled (what changes together), analyze how they couple, then assess by playing concrete "what if" scenarios from your domain. With two guardrails: MECE lists (Mutually Exclusive, Collectively Exhaustive: options that don't overlap and cover every case, so you compare comparable things and forget nothing) and the out-of-context trap (a generic winner can lose badly once your real constraints enter the room).

And one law that explains years of frustration: "an architect can never reduce semantic coupling via implementation, but they can make it worse" (ch. 11). If the business workflow is inherently tangled, no technology untangles it; tools can only mirror the domain or add accidental complexity on top. Hence the closing advice: "an architect adds real value to an organization not by chasing silver bullet after silver bullet but rather honing their skills at analyzing the trade-offs as they appear" (ch. 15).