A move away from a monolith is almost never one dramatic rewrite. Strong teams cut the system into small slices while keeping the right to roll back.
In real design work, the chapter shows how Strangler Fig, Branch by Abstraction, staged database separation, and measurable checks turn migration from a one-way bet into a managed program of change.
In interviews and engineering discussions, it helps frame migration through double-write risk, rollback paths, and the cost of each step rather than through a pretty target picture of services.
Practical value of this chapter
Design in practice
Move one scenario at a time: routing layer, new service, validation, then removal of old code.
Decision quality
Reduce migration risk with small slices, measurable checks, and a rollback path planned up front.
Interview articulation
Explain why a big-bang rewrite is risky and where old and new paths must temporarily coexist.
Failure framing
Plan rollback, double-write controls, and staged database separation.
Companion book
Building Microservices
Newman's first book explains what service architecture should look like; this one explains how to reach it safely from a monolith.
Monolith to Microservices
Authors: Sam Newman
Publisher: O'Reilly Media, 2019
Length: 272 pages
Sam Newman's book on incremental migration from a monolith: Strangler Fig, Branch by Abstraction, database separation, rollback paths, and double-write risk.
This chapter treats microservices not as a glossy target diagram, but as a migration playbook for an existing system. Newman focuses on migration seams, incremental service extraction, rollback paths, and difficult transition states such as dual writes while data is being split.
Why a separate book on migration?
Greenfield and brownfield work
Greenfield work lets you choose the architecture up front. Migration almost always starts from a brownfield system with users, data, integrations, and production constraints already in place.
Incremental migration
The book teaches small, reversible replacements for the monolith instead of a big-bang rewrite that puts the whole business on one bet.
Book structure
Chapters 1-2
Why migrate, when to stop, and how to choose the first safe slice.
Chapters 3-4
Patterns for decomposing code, extracting services, and splitting the database in stages.
Chapter 5
Growing pains: ownership, observability, organization, and the cost of coordination.
Chapter 1: just enough microservices
Three core microservice ideas
1. Independent deployability
If a service cannot be deployed independently from its neighbours, the team gets network complexity without real autonomy.
2. Domain-shaped modeling
A good boundary usually follows a bounded context and domain language, not a technical layer.
3. Data ownership
A service owns its data and exposes it through APIs, not through a shared database.
Types of monoliths
Single-process monolith
All code is deployed as one unit. That is not automatically bad while change remains manageable.
Modular monolith
A strong intermediate state: boundaries are visible, while operational complexity stays low.
Distributed monolith
It looks like services, but still requires shared releases, shared data, and constant coordination.
Chapter 2: planning the migration
When microservices are not yet needed
- The domain is still unclear — first learn where rules and language change.
- A startup is still searching for product shape — learning speed matters more than distributed architecture.
- The team is small — the operating cost of a service can outweigh the benefit.
- The engineering base is missing — CI/CD, monitoring, tracing, and release support come first.
How to choose the first service to extract
| Criterion | What to check |
|---|---|
| Low coupling | Few dependencies on neighbouring parts of the system and other teams. |
| Clear data boundaries | It is visible which tables and events belong to this bounded context. |
| A ready team | People are prepared to own the code, data, and operation. |
| Measurable value | Extraction reduces change latency, release risk, or support cost. |
Related book
Learning Domain-Driven Design
A deeper look at Event Storming, context maps, and strategic decomposition patterns.
Domain-Driven Design for decomposition
Event Storming
- Bring domain experts and developers into the same room.
- Identify domain events and business decisions.
- Group events into bounded contexts.
- Find future service boundaries and migration seams.
Context Map
- Shared Kernel — a shared slice of model changed only by agreement.
- Customer-Supplier — an explicit supplier-consumer dependency.
- Anti-Corruption Layer — a protective layer between the new model and the old system.
- Conformist — deliberate adaptation to an external API you cannot influence.
Chapter 3: decomposition patterns
Strangler Fig
Strangler Fig gradually moves scenarios out of the monolith and into a new path until the old implementation is no longer needed.
Proxy
Put a routing layer in front of the monolith.
Intercept
Select the scenarios that can move first.
Redirect
Route part of the traffic to the new service.
Remove
Delete old code after the new path stabilizes.
Branch by Abstraction
Branch by Abstraction lets a team replace an implementation inside the monolith without a long-lived branch or a high-risk release.
1. Introduce an abstraction
A stable interface separates callers from the implementation.
2. Add the new path
The new service implements the same contract and runs through parallel checks.
3. Shift traffic
A feature toggle lets the team enable the new path gradually.
Parallel Run
A parallel run keeps the old implementation as the source of the response while the new one calculates beside it and differences are inspected.
How it works:
- Call the old and new implementations.
- Compare results and side effects.
- Log mismatches and reasons.
- Return the trusted old response to the user.
Where it helps:
- Critical flows such as payments.
- Complex logic with edge cases.
- Situations where confidence is needed before traffic moves.
Decorating Collaborator
Decorating Collaborator adds behaviour next to the monolith: for example, audit, logging, or data enrichment as a cross-cutting concern.
Chapter 4: splitting the database
Why this is the hardest part
A shared database is the biggest obstacle to independent change. While services use one schema as their contract, they stay coupled through releases, migrations, and each other's mistakes.
Risks of a shared database:
- Schema changes require team coordination.
- Ownership of tables and rules is unclear.
- One flow's load affects everyone else.
- A service cannot scale or evolve independently.
Target state:
- Each service owns its data set.
- Access goes through the service API or events.
- The schema can change without shared releases.
- The team can choose the right database and storage model.
Data-splitting patterns
Database View
- Create a database view over monolith tables.
- The new service reads through a constrained layer.
- The old schema details are hidden from consumers.
- Useful for read-only access.
Database Wrapping Service
- Put an API service in front of shared tables.
- Clients access the data only through the API.
- The contract appears before tables physically move.
- It is a useful intermediate step toward real data ownership.
Synchronize Data in Application
- Copy the needed data into a new database.
- Application code keeps the copy in sync.
- Reads and writes gradually move to the new database.
- The temporary synchronization is removed after stabilization.
Change Data Capture (CDC)
- Changes are read from the database log or another source.
- CDC reduces pressure on the monolith.
- Tools such as Debezium or AWS DMS help build the change stream.
- The team must accept eventual consistency.
Working with transactions
After the database is split, simple ACID transactions across services disappear. They are replaced by local transactions, events, and compensating actions.
Saga
A saga breaks a long flow into steps with compensation when a later step fails.
Outbox
The outbox pattern writes data and an event in one local transaction.
Idempotency
Idempotency and idempotency keys make retries safe.
Chapter 5: growing pains
Common migration mistakes
- Too many services at once — start with one or two safe slices.
- Unclear ownership — decide who will operate the new service.
- The shared database stays too long — services quickly become a distributed monolith.
- No observability — the team cannot see where the new path breaks.
Organizational aspects
"If you have four teams working on a compiler, you'll get a 4-pass compiler."
Conway's Law
Inverse Conway Maneuver
First shape teams around the desired boundaries, then move the code.
You Build It, You Run It
The team that writes a service also owns how it runs after release.
Key takeaways
Do
- Migrate incrementally instead of rewriting the system in one push.
- Use Strangler Fig as the main pattern for safe scenario movement.
- Strengthen the modular monolith before extracting services.
- Plan data splitting together with code splitting.
Avoid
- Do not move everything at once without a rollback path.
- Do not leave the shared database as the main contract between services.
- Do not start migration before the domain boundaries are understood.
- Do not launch services without observability and clear ownership.
Who is this book for?
Best for:
- Teams operating a large monolith and trying to reduce change risk.
- Architects and tech leads planning a service migration.
- Engineers who need to argue for a path, not just a target architecture.
- Readers of Building Microservices who are now facing the real transition.
How it connects to other books:
- Building Microservices — the target model of service architecture.
- Monolith to Microservices — a safer path out of a running system.
- DDIA — deeper trade-offs around distributed data and consistency.
Reading tip: treat this book as the practical sequel to Building Microservices. It does not pretend the transition is easy; it helps break it into steps that can be tested, rolled back, and explained to the business.
Related chapters
- Building Microservices (short summary) - The target-state principles of microservice architecture that this book turns into an incremental migration path.
- Why microservices and integration are needed - Introductory framing for service boundaries, API contracts, and integration before planning a monolith migration.
- Decomposition Strategies - A practical map for choosing bounded contexts and extracting services without stopping the running system.
- Learning Domain-Driven Design (short summary) - DDD foundations for domain boundaries and contracts that reduce the risk of building a distributed monolith.
- Introducing Domain-Oriented Microservice Architecture - Uber's case study on large-scale domain transformation and organizational change toward service architecture.
- Modular Monolith and Microservices - Context for when a modular monolith is a rational intermediate step before a full microservice split.