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
Design service boundaries together with data ownership and team responsibility.
Decision quality
Connect deployment, testing, and observability into one engineering system.
Interview articulation
Show not only the service target state, but also the safe path toward it.
Failure framing
Account for platform gaps: CI/CD, tracing, contract governance, and on-call support.
Companion book
From monolith to microservices
The practical follow-up: how to apply Newman's ideas while migrating an existing system.
Building Microservices, 2nd Edition
Authors: Sam Newman
Publisher: O'Reilly Media, 2021 (2nd Edition)
Length: 612 pages
Sam Newman's book on service boundaries, independent deployment, communication, data ownership, testing, observability, and the operating cost of microservices.
This chapter treats microservice architecture as a system of service boundaries, independent deployability, data ownership, deployment discipline, contract testing, observability, and resilience. Newman keeps returning to the same point: microservices are useful only when the surrounding engineering system can support them.
The book's core idea is simple and uncomfortable: microservices buy autonomy at the cost of distributed complexity, so they cannot be evaluated separately from teams, data, platforms, and operations.
Book structure
The second edition works well as a route: first understand where service boundaries should be, then learn how to ship and connect services, and finally evaluate the organizational cost of that choice.
Part I: Foundations
What makes a service a microservice, how to choose boundaries, and how to split monoliths and data.
Part II: Implementation
Communication, business workflows, deployment, testing, observability, and security.
Part III: Operations
Resilience, scaling, team structures, and the true ownership cost of microservices.
Part I: microservice foundations
What makes a service a microservice
Good signals:
- The service can be deployed independently from its neighbors.
- The boundary wraps a clear business capability.
- The team owns the code, data, and operation of the service.
- The integration contract can evolve without breaking clients.
When not to rush:
- The domain is still unclear and changes shape frequently.
- The team is too small for the extra operational load.
- The split creates more network failure than autonomy.
- A shared datastore remains the real contract between services.
Related book
Learning Domain-Driven Design
A deeper look at bounded contexts, model language, and relationships between teams.
Modeling service boundaries
DDD helps teams split more than code: it finds where rules, language, and responsibility change.
Bounded context
- its own rules and model language
- clear ownership and understandable change
- one context may contain one or several services
Context map
- shows who provides a model and who consumes it
- makes partnership, conformity, or protective translation explicit
- turns boundary debates from taste into architecture decisions
Splitting the monolith
Newman does not recommend rewriting everything. He shows how to extract behavior gradually while keeping risk under control.
Strangler Fig
Old functionality is gradually replaced by a new service behind a stable route.
Branch by Abstraction
An abstraction separates callers from old and new implementations until the cutover is safe.
Parallel run
Old and new paths run side by side while the team compares behavior and reduces risk.
Splitting data
How to separate storage:
- Database per service as the target state.
- A shared database only as a temporary migration stage.
- A database view for limited read access.
- A database wrapping service when direct access must be closed gradually.
How to synchronize changes:
- Change data capture through Debezium to synchronize the old and new paths.
- The Saga pattern for business operations across several services.
- The outbox pattern for reliable event publication.
- Explicit handling of eventual consistency rather than hoping data matches instantly.
Part II: implementation
Related case
API Gateway
A practical example of one entry point: routing, access control, limits, and BFF.
Communication between services
Synchronous interaction:
REST
simplicity, compatibility, and clear documentation through OpenAPI
gRPC
strict contracts, high performance, and good ergonomics for internal calls
GraphQL
flexible data selection when clients differ in what they need
Asynchronous interaction:
Message brokers
Kafka, RabbitMQ, and AWS SQS decouple senders from receivers
Event-driven style
services publish facts instead of calling neighbors directly
Asynchronous request-response
correlation IDs and reply queues are needed when results arrive later
Business workflows across services
Long-running business scenarios rarely fit into one request, so teams need to choose where coordination lives and how compensation happens.
Orchestration
- there is an explicit process coordinator
- state and failures are easier to see
- fits complex business scenarios with compensation
- can become a central point of coupling
Choreography
- each service reacts to events
- there is less central control
- the full process is harder to reconstruct
- requires mature observability and event discipline
Build and deployment
Continuous delivery turns microservices from a set of repositories into a system that can be shipped in small, safe steps.
Container images
Docker and an image registry make service delivery reproducible.
Kubernetes
The platform handles scheduling, service discovery, and instance recovery.
GitOps
ArgoCD and Flux keep environments declarative and auditable.
Testing
The more services there are, the more important it becomes to separate fast checks inside one service, contract checks, and expensive end-to-end scenarios.
Unit
Confirms: Business rules inside one service
Examples: JUnit, pytest, Jest
Integration
Confirms: Datastores, brokers, external APIs
Examples: Testcontainers, WireMock
Contract
Confirms: Compatibility between provider and consumer
Examples: Pact, Spring Cloud Contract
End-to-end
Confirms: A critical user journey
Examples: Cypress, Playwright
Observability and security
Observability:
- structured logs and a shared search surface
- service metrics through Prometheus and Grafana
- request tracing through Jaeger, Zipkin, or OpenTelemetry
Security:
- mTLS and a service mesh through Istio or Linkerd
- API Gateway for access checks and rate limiting
- Zero Trust and secret management through Vault or cloud services
Part III: people and operations
Resilience and scaling
Resilience patterns:
- Circuit breaker - stops calls to a degraded dependency quickly
- Bulkhead - limits the blast radius of a failure
- Timeout - keeps a request from waiting forever
- Retry with backoff - reduces the risk of overloading an already unhealthy dependency
Scaling:
- Horizontal scaling - adds service instances instead of making one node larger
- Auto-scaling - changes the instance count based on load metrics
- Caching - reduces pressure on expensive dependencies through Redis or a CDN
- CQRS - separates command and read paths when they need different models
Organizational structures
"Organizations that design systems are constrained to produce designs that mirror their own communication structures."
- Conway's Law
Team topology:
- Stream-aligned teams - own a business flow from code to operation
- Platform teams - provide an internal platform and remove repeated infrastructure work
- Enabling teams - temporarily strengthen product teams with expertise
- Complicated-subsystem teams - own rare technically complex parts of the system
Ownership practices:
- Two-Pizza Team: a small autonomous group with a clear ownership area.
- You Build It, You Run It: the team operates what it ships.
- Internal Open Source: teams can improve neighboring services through agreed rules.
- Inverse Conway Maneuver: team structure changes to support the desired architecture.
Key takeaways
Do:
- Start with a monolith when the domain is still unclear.
- Treat independent deployability as the main practical criterion for a microservice.
- Design data ownership together with service boundaries.
- Invest in observability and contract checks from day one.
Avoid:
- Split into services only because microservices sound modern.
- Create a distributed monolith with shared releases and a shared database.
- Leave a shared database as the long-term contract between teams.
- Ignore organization structure: it will still show up in the architecture.
Who this book is for
Especially useful for:
- architects designing service boundaries;
- tech leads responsible for product and team evolution;
- developers in growing teams where one monolith is slowing change;
- candidates preparing to discuss microservices in system design interviews.
Best read with:
- experience building web applications;
- a basic understanding of distributed systems;
- general familiarity with Docker and Kubernetes;
- willingness to discuss teams, releases, and operations, not just code.
Tip: read it alongside DDIA: Kleppmann gives the deeper theory of distributed data, while Newman shows how that theory becomes teams, services, contracts, and operational practice.
Related chapters
- Why microservices and integration are needed - The section map for service boundaries, API contracts, and the trade-offs between integration styles.
- Decomposition Strategies - A practical decision map for service boundaries before teams start extracting code and data.
- Learning Domain-Driven Design (short summary) - The DDD foundation for bounded contexts, model language, and more durable ownership boundaries.
- Inter-Service Communication Patterns - The next layer after Newman's book: synchronous calls, asynchronous messages, timeouts, and resilient contracts.
- Monolith to Microservices (short summary) - The practical companion: how to migrate from a monolith to services without stopping the product or betting on a big bang.
- Software Architecture: The Hard Parts (short summary) - A deeper look at distributed decisions: data ownership, transactions, and coordination between services.