Sam Newman’s book matters not because it sells microservices, but because it shows their full cost.
In real design work, the chapter shows how decomposition, communication, deployment, testing, and organizational patterns have to form one operating system rather than a set of unrelated practices.
In interviews and engineering discussions, it helps frame microservices through platform gaps: missing CI/CD, tracing, contract governance, and the other foundations without which a service architecture quickly degrades.
Practical value of this chapter
Design in practice
Build a migration runway with controlled coexistence of legacy and new service paths.
Decision quality
Treat delivery, observability, and platform capabilities as one operational package.
Interview articulation
Show how target architecture turns into a realistic incremental rollout.
Failure framing
Account for platform gaps: missing CI/CD, tracing, and contract governance.
Companion Book
From monolith to microservices
A Practical Guide to Monolith Migration - How to put the theory in this book into practice.
Building Microservices, 2nd Edition
Authors: Sam Newman
Publisher: O'Reilly Media, 2021 (2nd Edition)
Length: 612 pages
Analysis of Sam Newman's book: decomposition, communication, deployment, testing and organizational patterns.
Book structure
The book is divided into three logical parts, covering the entire path from basics to advanced topics:
Part I: Basics
What are microservices, how to model them, monolith decomposition and partitioning patterns.
Part II: Implementation
Communication between services, workflow, build/deploy, testing, observability.
Part III: People
Organizational structures, security, resilience and scaling.
Part I: Microservices Basics
Chapter 1: What are microservices?
Key Features:
- Independent deployability - main criterion
- Modeling around a business domain
- Owning your data
- Technological flexibility
When NOT to use:
- Small team (up to 5-10 people)
- An incomprehensible domain - at first a monolith
- Early stage startup
- No experience in distributed systems
Related book
Learning Domain-Driven Design
Deep dive into DDD: strategic and tactical design, bounded contexts, context maps.
Chapter 2: How to Model Microservices
Domain-Driven Design as a basis for decomposition:
Bounded Context
- Clear domain boundaries
- Own ubiquitous language
- One context = one (or more) services
Context Maps
- Customer-Supplier
- Conformist
- Anticorruption Layer
- Open Host Service
Chapter 3: Breaking the Monolith
Practical migration patterns from monolith to microservices:
Strangler Fig
Gradual replacement of functionality with new services
Branch by Abstraction
Abstraction → new implementation → switching
Parallel Run
Running old and new versions in parallel
Chapter 4: Database Partitioning
Data partitioning patterns:
- Database per Service - ideal
- Shared Database - temporary compromise
- Database View - readonly access
- Database Wrapping Service
Working with data:
- Change Data Capture (Debezium)
- Saga pattern for transactions
- Eventual consistency
- Outbox pattern
Part II: Implementation
Related case
API Gateway
Centralization of communication: routing, authentication, rate limiting and BFF pattern.
Chapter 5: Communication between services
Synchronous communication:
REST
Simplicity, wide support, OpenAPI
gRPC
Performance, typing, streaming
GraphQL
Query flexibility, federation
Asynchronous communication:
Message Brokers
Kafka, RabbitMQ, AWS SQS
Event-Driven
Loose coupling, eventual consistency
Request-Response async
Correlation IDs, reply queues
Chapter 6: Workflow
How to implement business processes spanning multiple services:
Orchestration
- Central Coordinator
- Saga Execution Coordinator
- Temporal, Camunda, AWS Step Functions
- Easier to track, harder to scale
Choreography
- Each service reacts to events
- Loose coupling
- More difficult to debug
- Implicit workflow through event sourcing
Chapter 7: Build and Deploy
Continuous Delivery as the basis of successful microservices:
Containers
Docker, images, registry
Kubernetes
Orchestration, service discovery
GitOps
ArgoCD, Flux, declarative deployment
Chapter 8: Testing
Testing strategy in the world of microservices:
| Type of tests | What does it test? | Tools |
|---|---|---|
| Unit | Business logic inside the service | JUnit, pytest, Jest |
| Integration | Interaction with the database, external APIs | Testcontainers, WireMock |
| Contract | API contracts between services | Pact, Spring Cloud Contract |
| E2E | Complete user journey | Cypress, Playwright |
Chapters 9-10: Observability and Security
Three Pillars of Observability:
- Logs - structured, aggregated (ELK)
- Metrics — Prometheus, Grafana
- Traces — Jaeger, Zipkin, OpenTelemetry
Security:
- mTLS — service mesh (Istio, Linkerd)
- API Gateway — authentication, rate limiting
- Zero Trust — verify everything
- Secrets Management — Vault, AWS Secrets
Part III: People and Organization
Chapters 11-12: Resilience and Scaling
Resilience patterns:
- Circuit Breaker — failure isolation
- Bulkhead - blast radius limitation
- Timeout - don't wait forever
- Retry with backoff - smart repetitions
Scaling:
- Horizontal scaling - more instances
- Auto-scaling - by metrics
- Caching — Redis, CDN
- CQRS - read/write separation
Chapter 13-14: Organizational Structures
"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."
— Conway's Law
Team Topologies:
- Stream-aligned teams - according to business flow
- Platform teams - internal platform
- Enabling teams - helping other teams
- Complicated-subsystem teams - specialists
Practices:
- Two-Pizza Teams — 6-8 people
- You Build It, You Run It
- Internal Open Source
- Inverse Conway Maneuver
Key Findings
Do:
- Start with a monolith if the domain is unclear
- Independent deployability is the main criterion
- Database per service with eventual consistency
- Invest in observability from day one
Don't:
- Microservices for the sake of microservices
- Distributed monolith - the worst of both worlds
- Shared database between services for a long time
- Ignore organizational structure
Who is this book for?
Ideal for:
- Architects planning a migration to microservices
- Tech leads, architectural decision makers
- For developers in growing teams
- To everyone preparing for System Design interviews
Prior knowledge:
- Experience with web applications
- Basic understanding of distributed systems
- Familiarity with Docker/Kubernetes (preferred)
Advice: Read along with DDIA - Kleppmann gives a deep theory of distributed systems, and Newman gives practical patterns for their organization in production.
Related chapters
- Why microservices and integration are needed - Intro map of integration constraints and service boundaries that frames Newman’s practical microservices guidance.
- Decomposition Strategies - Practical decomposition workflow for bounded contexts and service boundaries before implementation decisions.
- Learning Domain-Driven Design (short summary) - DDD foundation for domain modeling, ownership boundaries, and resilient contracts between services.
- Inter-Service Communication Patterns - Continuation of synchronous/asynchronous communication patterns, reliability mechanisms, and operating trade-offs.
- Monolith to Microservices (short summary) - Companion chapter focused on step-by-step migration from legacy monoliths to target microservice architecture.
- Software Architecture: The Hard Parts (short summary) - Deep dive into difficult distributed trade-offs: data ownership, transactions, and orchestration/choreography patterns.