Companion Book
Building Microservices
The theory and target state of microservice architecture is what to build, and this book is about how to get there.
Monolith to Microservices
Authors: Sam Newman
Publisher: O'Reilly Media, 2019
Length: 272 pages
Analysis of the book Sam Newman: Strangler Fig, Branch by Abstraction, database division and practical migration patterns.
Original
TranslatedWhy a separate book on migration?
Greenfield vs Brownfield
"Building Microservices" describes an ideal world. But 90% of projects are legacy systems that need to be transformed without stopping production.
Incremental migration
The book provides specific patterns for a gradual transition - without “big bang” rewriting and with minimal risk to the business.
Book structure
Chapters 1-2
Why migrate? When NOT to migrate? Migration planning.
Chapters 3-4
Patterns for code decomposition and database partitioning.
Chapter 5
Problems of growth and organizational aspects of migration.
Chapter 1: Just Enough Microservices
Three Key Ideas of Microservices
1. Independent Deployability
The ability to deploy a service without coordination with other teams is the main criterion for proper microservices.
2. Modeling by domain
Service boundaries = business domain boundaries. DDD and Bounded Contexts as a basis.
3. Data ownership
Each service owns its data and hides it behind an API. No shared database.
Types of monoliths
Single-Process
All code in one deployable unit. The most common type.
Modular Monolith
Inside it is divided into modules, but deployed as a single whole. A good in-between option!
Distributed Monolith
The worst option is formally services, but they are all closely connected. The complexity of both worlds.
Chapter 2: Planning for Migration
When are microservices NOT needed?
- Unclear domain - understand the business first
- Startup — speed is more important than architecture
- Small team - the overhead will outweigh the benefits
- No DevOps culture — CI/CD and monitoring first
How to choose the first service to highlight?
| Criterion | Description |
|---|---|
| Low engagement | Minimum dependencies on other parts of the system |
| Clear data boundaries | It is clear which tables “belong” to this domain |
| The team is ready | There are people capable of owning an end-to-end service |
| Business Value | Dedication will provide measurable benefits |
Related book
Learning Domain-Driven Design
A complete guide to DDD: Event Storming, Context Maps, strategic patterns for decomposition.
Domain-Driven Design for Decomposition
Event Storming
- We gather domain experts and developers
- Identifying domain events (orange stickers)
- Grouping in Bounded Contexts
- Finding the boundaries of future services
Context Maps
- Shared Kernel - general code
- Customer-Supplier — upstream/downstream
- Anticorruption Layer - protection against legacy
- Conformist — adapt to external API
Chapter 3: Decomposition Patterns
Strangler Fig Pattern
The main migration pattern is the gradual “wrapping” of new services around the monolith until there is nothing left of the old system.
Proxy
We put a proxy in front of the monolith
Intercept
We intercept the necessary calls
Redirect
Referring to a new service
Remove
Removing code from the monolith
Branch by Abstraction
To isolate functionality from inside the monolith:
1. Create an abstraction
Interface around code highlighting
2. New implementation
Microservice implementing an interface
3. Switching
Feature toggle → remove old code
Parallel Run
We run the old and new implementation in parallel and compare the results:
How it works:
- Call both implementations
- Comparing the results
- Logging discrepancies
- Returning the result of the “old” version
When to use:
- Critical functionality (payments)
- Complex logic with edge cases
- Need confidence in correctness
Decorating Collaborator
We add new functionality through a proxy service without changing the monolith. Useful for cross-cutting concerns: logging, auditing, data enrichment.
Chapter 4: Database Partitioning
Why is this the hardest part?
Shared database is the main obstacle to independent deployment. While services share a common database, they are not true microservices.
Shared DB problems:
- Schema change requires coordination
- No clear data ownership boundaries
- The performance of one affects all
- Cannot scale independently
Target:
- Each service owns its own data
- Data is available only through the service API
- You can change the scheme without coordination
- You can choose the appropriate DBMS
Data partitioning patterns
Database View
- Creating a view on top of the monolith tables
- The new service reads through view
- Hiding the details of the circuit
- Read only!
Database Wrapping Service
- API service before shared tables
- Everyone accesses only through the API
- Then we transfer the tables to the service
- A good intermediate step
Synchronize Data in Application
- Duplicate data into a new database
- Synchronize via application code
- Switching to a new database
- Removing synchronization
Change Data Capture (CDC)
- Debezium, AWS DMS
- Streaming changes in real time
- Minimal impact on the monolith
- Eventual consistency
Working with transactions
After dividing the database, we lose ACID transactions between services. Alternatives:
Saga Pattern
A chain of local transactions with compensating actions in case of error.
Outbox Pattern
We atomically write the data + event into one database, then publish it.
Idempotency
Secure recalls using idempotency keys.
Chapter 5: Growing Pains
Common mistakes during migration
- Too many services at once - start with 1-2
- Ignoring ownership - who will support?
- Shared database for a long time - creates distributed monolith
- No observability - don’t see what’s happening
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, reorganize the teams by domain, then migrate the code.
You Build It, You Run It:
The team that writes the service is responsible for its operation in production.
Key Findings
Do:
- Incremental migration, not big bang
- Strangler Fig as the main pattern
- First modular monolith, then microservices
- Allocate the service database as early as possible
Don't:
- Migrate everything at once
- Shared database between services for a long time
- Migrate without understanding the domain
- Start without observability
Who is this book for?
Ideal for:
- Teams with a legacy monolith
- Architects planning migration
- Tech leads looking for practical patterns
- To everyone who has already read "Building Microservices"
Connection with other books:
- Building Microservices — theory and target state
- Monolith to Microservices - how to get there
- DDIA — deep understanding of distributed data
Advice: This book is the perfect companion to "Building Microservices". The first book tells What are microservices, the second is How come to them from the existing monolith.