Sam Newman wrote Building Microservices, one of the first books on the topic. This follow-up is narrower and, I think, more useful for most teams: it assumes you already have a working system and asks whether, when and how to break it apart without stopping everything else. The answer is a catalogue of migration patterns wrapped in a lot of careful scepticism.

The book's two messages are simple. Decide based on your own goals and context rather than copying famous companies, and if you do migrate, do it incrementally, in small steps that reach production and can be reversed. Almost every pattern in the book, from the strangler fig to sagas, exists to make those small steps possible.

What I value most is how often Newman argues against his own topic. He calls the monolith a valid choice, recommends the modular monolith for many organisations, and lists a cheaper alternative for every common reason to adopt microservices. In 2026, after a period in which many teams have publicly consolidated services, that balance reads as foresight.

Who this book is for

  • Backend and full-stack developers working on a large existing system that has become slow to change.
  • Tech leads and architects preparing a migration proposal, or asked to evaluate one.
  • Engineering managers who need to understand the organisational side: team ownership, skills, and how to tell whether a migration is working.
  • Frontend developers on teams going through a split. The UI composition section and the data chapter explain many decisions that will otherwise arrive as surprises.

You do not need to have read Building Microservices first. Newman introduces just enough of the concepts in chapter 1, and points to the bigger book for depth on communication, deployment and testing.

How to read it

The book is about 270 pages with six chapters, and they are not equal.

  1. Chapter 1 (essential). Definitions, kinds of monolith, coupling and just enough DDD. Short and foundational.
  2. Chapter 2 (essential, read slowly). Whether to migrate at all, alternatives for each goal, where to start, team changes and how to measure progress. This is the chapter to bring to planning meetings.
  3. Chapter 3 (essential, use as a reference). The code migration patterns. Read the strangler fig and branch by abstraction sections fully; skim the protocol examples unless they match your system.
  4. Chapter 4 (essential if you own data). The longest chapter. Read the shared database, sequencing and saga sections carefully; the schema-level patterns can be revisited when you meet the specific problem.
  5. Chapter 5 (skim, then revisit). Growing pains, organised by when they tend to appear. Read it once for awareness and again when your service count grows.
  6. Chapter 6. A short coda.

A realistic plan is one or two weeks at a chapter every couple of days. To practise, take one feature of a system you know, place it on Newman's ease and value axes, and sketch which pattern from chapter 3 and which from chapter 4 you would use to extract it. Even if you never split it, the exercise exposes hidden coupling.

Still worth reading in 2026?

Yes. I found no newer edition of this book; it is still the 2019 first edition. The companion Building Microservices received a second edition in August 2021, which covers communication styles, deployment, testing, security and team organisation in far more depth, so the two pair well: this one for the migration journey, that one for the destination.

What has aged is mostly tooling detail. Service meshes, which Newman advised waiting on, have matured (Istio's sidecar-less ambient mode reached general availability in November 2024). OpenTelemetry, which graduated in the CNCF in May 2026, has made tracing a standard rather than a vendor choice. The book does not name the outbox pattern, which is now the usual way to publish events reliably, and Debezium has become a common choice for change data capture.

What has aged well is the judgement. The industry has swung towards modular monoliths and away from splitting by default, which is close to the position Newman takes throughout. Read it alongside:

  • Building Microservices, 2nd edition, for the target architecture.
  • Team Topologies, for team design during the migration.
  • Current documentation for the tools you choose: OpenTelemetry, Debezium, Pact, and your platform's routing and feature flag tools.

What this guide covers

  • Just enough microservices: independent deployability, kinds of monolith, four forms of coupling and the essentials of aggregates and bounded contexts.
  • Planning a migration: the three key questions, cheaper alternatives, when not to migrate, choosing where to start and measuring progress.
  • Splitting the monolith: strangler fig, UI composition, branch by abstraction, parallel run, decorating collaborator and change data capture.
  • Decomposing the database: shared database coping patterns, data ownership, tracer writes, schema-first versus code-first, foreign keys, reference data and sagas.
  • Growing pains: the ten problems that appear as the number of services grows, how to spot each early, and the closing words.

About these notes

These are my personal reading notes, written in my own words with my own examples, mostly from an online course platform rather than the book's Music Corp. They aim to help you decide whether and how to read the book and to connect it to 2026 practice. They do not replace it: the case studies, the reasoning behind each pattern and the many "where to use it" judgements are only in the book.

The book is available from O'Reilly.