Building Microservices

Overview

Building Microservices: Designing Fine-Grained Systems (2nd Edition, 2021) by Sam Newman is the definitive guide to designing, building, and operating systems composed of independently deployable services. Newman draws on over a decade of experience at ThoughtWorks and as an independent consultant to provide practical, battle-tested advice.

The book covers the full lifecycle: service decomposition, inter-service communication, data management, deployment, testing, monitoring, and the organizational changes required for success.

---

------|-------|------------| | I: Foundation | What and why | Benefits, drawbacks, decomposition, organizational alignment | | II: Implementation | How | Integration, data, deployment, testing, monitoring, security | | III: People | Who | Team topology, Conway's Law, organizational change |

The core thesis: independent deployability is the defining characteristic of microservices. Everything else — technology heterogeneity, resilience, scalability, team autonomy — follows from it.

---

Key Takeaways

1. Independent deployability is the key metric — If you cannot deploy a service without deploying others, you have distributed monolith, not microservices.

2. Decompose by business capability — Use bounded contexts from Domain-Driven Design to identify service boundaries. Stable, cohesive boundaries are the hardest and most important design decision.

3. Smart endpoints, dumb pipes — Services communicate via technology-agnostic APIs (REST, gRPC, messaging). Keep middleware simple; put intelligence in the services themselves.

4. Each service owns its data — Shared databases create coupling that undermines independent deployability. Each service manages its own data store, even if that means data duplication.

5. Embrace eventual consistency — Distributed transactions (2PC) do not scale. Use sagas with compensating actions for multi-service operations.

6. Observability is not optional — Distributed systems fail in complex, unpredictable ways. Centralized logging, metrics aggregation, and distributed tracing are mandatory.

7. Test at the right level — Prefer consumer-driven contract tests over brittle end-to-end tests. Use testing layers: unit, integration, contract, end-to-end.

8. Containers enable consistency — Docker and Kubernetes provide consistent environments from development to production, solving the "it works on my machine" problem.

9. Organize teams around services — Conway's Law in reverse: design your organization so team boundaries mirror service boundaries. Small, cross-functional teams own services end-to-end.

10. Start monolithic, then split — Premature decomposition creates wrong boundaries. Build a well-structured monolith first, then extract services as patterns emerge.

---

Who Should Read

| Reader Type | Why | |---|---| | Architects and senior developers | Foundational text for distributed system design | | DevOps/platform engineers | Deployment, monitoring, and operational guidance | | Technical managers | Organizational patterns and team topology | | Full-stack developers transitioning to backend | Context for service design decisions |

---

Who Should Skip

• Developers looking for a programming tutorial — this is an architectural guide, not a code recipe book
• Teams with simple, small-scale applications that don't need distributed systems
• Readers already deeply familiar with Fowler's enterprise patterns and DDD

---

Core Themes

| Theme | Description | |-------|-------------| | Independent Deployability | The defining goal of microservice architecture | | Bounded Contexts | Service boundaries derived from domain models | | Choreography over Orchestration | Loose coupling via event-driven coordination | | Observability | Monitoring, logging, and tracing as first-class concerns | | Evolutionary Architecture | Systems that adapt to changing requirements | | Team Autonomy | Organizational structures that enable independent delivery |

---

Why This Book Matters

The first edition (2015) arrived at the peak of the microservices hype cycle, when every organization wanted to "go microservices" without understanding the costs. Newman provided a sober, balanced view — listing more drawbacks than benefits — that helped practitioners make informed trade-offs.

The second edition (2021) matured with the industry, adding depth on Kubernetes, serverless, event-driven architectures, and organizational patterns. It remains the most comprehensive single-volume treatment of microservices.

---

Related Books

| Book | Author | Connection | |------|--------|------------| | Monolith to Microservices | Sam Newman | Companion guide focused on the migration journey | | Designing Data-Intensive Applications | Martin Kleppmann | Deep dive into distributed data systems underpinning microservices | | Clean Architecture | Robert C. Martin | Architectural principles that complement microservice design | | Release It! | Michael Nygard | Production-hardening patterns for distributed systems | | Domain-Driven Design | Eric Evans | The conceptual foundation for service boundaries |

---

Final Verdict

Building Microservices is the most pragmatic, comprehensive guide to microservice architecture available. Newman's willingness to discuss disadvantages with equal weight to advantages sets it apart from the evangelical literature.

The book's length (612 pages) is both a strength and a weakness: it is exhaustive, but some sections (particularly on monitoring and CI/CD) have aged faster than others. The organizational and architectural guidance, however, remains timeless.

Limitations: the book is O'Reilly-practical rather than academically rigorous. It does not deeply explore formal distributed systems theory (CAP theorem, consensus algorithms). Readers wanting theoretical depth should complement with Kleppmann's Designing Data-Intensive Applications.

Rating: 8.5/10 — The essential field guide to microservices, best read alongside Kleppmann for theory and Fowler for patterns.

The Microservice Architecture

flowchart TB
    subgraph Client_Layer["Client Layer"]
        Mobile["Mobile App"]
        Web["Web App"]
        External["External API Consumers"]
    end

    subgraph API_Gateway["API Gateway"]
        GW["Gateway<br/>(Routing, Auth, Rate Limiting)"]
    end

    subgraph Services["Microservices"]
        direction TB
        S1["Service A<br/>(Orders)"]
        S2["Service B<br/>(Payments)"]
        S3["Service C<br/>(Inventory)"]
        S4["Service D<br/>(Notifications)"]
    end

    subgraph Data["Data Layer"]
        DB1["Own DB A"]
        DB2["Own DB B"]
        DB3["Own DB C"]
        DB4["Own DB D"]
    end

    subgraph Infrastructure["Infrastructure & Observability"]
        LOG["Centralized Logging<br/>(ELK Stack)"]
        MET["Metrics & Alerting<br/>(Prometheus + Grafana)"]
        TRACE["Distributed Tracing<br/>(Jaeger/Zipkin)"]
        CI["CI/CD Pipeline"]
        ORCH["Container Orchestration<br/>(Kubernetes)"]
    end

    Mobile --> GW
    Web --> GW
    External --> GW
    GW --> S1
    GW --> S2
    GW --> S3
    GW --> S4
    S1 -.->|"Async Events"| MQ["Message Broker<br/>(Kafka/RabbitMQ)"]
    S2 -.-> MQ
    S3 -.-> MQ
    S4 -.-> MQ
    S1 --> DB1
    S2 --> DB2
    S3 --> DB3
    S4 --> DB4
    S1 -.-> LOG
    S2 -.-> LOG
    S3 -.-> LOG
    S4 -.-> LOG
    S1 -.-> MET
    S1 -.-> TRACE

---

Part I: Foundation

What Are Microservices?

Microservices are independently deployable services that model a single business domain. They communicate over a network, each owning its own data and technology stack.

The key distinction from SOA: microservices are fine-grained and independently deployable. SOA often shared databases and middleware; microservices do not.

Benefits vs. Drawbacks

Newman lists six benefits and nine drawbacks — a deliberate asymmetry that signals his balanced perspective:

| Benefits | Drawbacks | |----------|-----------| | Technology heterogeneity | Technology overload | | Robustness | Latency | | Scalability | Data consistency | | Ease of deployment | Developer experience overhead | | Organizational alignment | Cost | | Composability | Monitoring and troubleshooting | | Security | Reporting | | Testing | | | | Network reliability |

Service Decomposition

The hardest design decision: where to draw service boundaries.

Newman recommends Domain-Driven Design's bounded contexts as the primary heuristic. A bounded context is the boundary within which a particular domain model applies. Services should map one-to-one with bounded contexts.

Other decomposition heuristics:

• Business capability — Align services with business functions (orders, payments, shipping)
• Change patterns — Things that change together should be in the same service
• Conway's Law — Organizations produce systems that mirror their communication structures
• Volatility — High-churn modules may benefit from isolation

---

Part II: Implementation

Integration Styles

Newman covers three primary integration approaches:

REST

The default choice for most services. RESTful HTTP APIs are technology-agnostic, widely understood, and cacheable. Newman recommends using hypermedia controls (HATEOAS) cautiously — pragmatic REST (JSON over HTTP with sensible URL conventions) is usually sufficient.

gRPC

Suitable when both client and server are within your control and performance matters. Strong typing, streaming, and code generation make gRPC attractive for internal service-to-service communication. The downside: gRPC requires significant infrastructure.

Messaging

Asynchronous message brokers (Kafka, RabbitMQ, Amazon SQS) decouple services in time and space. Events become the integration surface. Newman prefers messaging for high-volume, loosely-coupled interactions.

Data Management

Each service owns its data store. This is non-negotiable. Sharing databases between services recreates the coupling problems of monoliths.

Consequences of per-service databases:

• Data duplication across services is acceptable
• Eventually, you need distributed transactions (sagas)
• Reporting and analytics require an event-sourcing or CQRS approach

Sagas

A saga is a sequence of local transactions where each step publishes an event that triggers the next step. If a step fails, compensating transactions undo the previous steps.

flowchart LR
    subgraph Successful_Saga["Successful Order Saga"]
        O["Create Order"] --> P["Reserve Payment"]
        P --> R["Reserve Inventory"]
        R --> C["Confirm Order"]
        C --> N["Send Notification"]
    end

    subgraph Failed_Saga["Failed Order Saga (Rollback)"]
        O2["Create Order"] --> P2["Reserve Payment"]
        P2 --> X["INVENTORY FAILS"]
        X --> COMP1["Compensate: Release Payment"]
        COMP1 --> COMP2["Compensate: Cancel Order"]
    end

Deployment

Newman strongly advocates for containers (Docker) and orchestration (Kubernetes). Consistent environments from dev to prod eliminate the most common deployment failure: environmental differences.

He also covers serverless (AWS Lambda, Cloud Functions) as a deployment model that removes infrastructure management entirely — appropriate for event-driven, low-volume services.

Testing

Testing distributed systems requires a layered approach:

1. Unit tests — Test individual functions in isolation
2. Integration tests — Test service boundary with real dependencies
3. Consumer-driven contract tests — Verify that a service meets its consumers' expectations without deploying both services
4. End-to-end tests — The most expensive, least reliable; use sparingly for critical user journeys

Newman emphasizes contract tests (backed by tools like Pact) as the sweet spot for microservice testing — they catch integration issues without the fragility of end-to-end tests.

Monitoring & Observability

Three pillars of observability:

• Logging — Structured, centralized logs (ELK stack, Splunk)
• Metrics — Aggregated time-series data (Prometheus, Grafana)
• Tracing — Request-scoped correlation across services (Jaeger, Zipkin)

Correlation IDs are the simplest and most impactful practice: pass a unique ID through every service call so you can trace a request end to end.

---

Part III: People

Organizational Alignment

Conway's Law: organizations design systems that mirror their communication structures. The inverse is also true: if you want microservices, you need small, cross-functional teams that can own services end to end.

Newman recommends the Spotify model (squads, tribes, chapters, guilds) as one organizational pattern, but emphasizes that team topology must be tailored to the organization.

When to Avoid Microservices

• Startups — No stable service boundaries yet; teams are small
• Consumer software — Operating a distributed system for shrink-wrapped software imposes unacceptable operational burden
• Simple applications — A monolith with clean internal modularity is often the right answer

---

Key Lessons

• Independent deployability is the defining goal of microservices
• Service boundaries are the hardest and most consequential design decision — get them wrong and you get a distributed monolith
• Each service must own its data; shared databases are the enemy
• Prefer eventual consistency and sagas over distributed transactions
• Contract tests are the sweet spot for integration testing
• Observability (logging, metrics, tracing) is non-negotiable
• Containers and orchestration standardize the deployment pipeline
• Organizational structure must align with service architecture
• Start monolithic; split only when boundaries become clear
• Understand the drawbacks as thoroughly as the benefits

---

Practical Applications

Migration Strategy

For organizations migrating from a monolith, Newman recommends the Strangler Fig pattern: gradually replace monolithic functionality with microservices, routing traffic to the new service while keeping the old code path until it is fully replaced.

Service Template

Standardize each service with a template that includes:

• Dockerfile and CI/CD pipeline
• Health check endpoint
• Metrics endpoint (Prometheus format)
• Structured logging setup
• Service discovery registration
• Correlation ID middleware

Team Structure

Organize into small (5-9 person), cross-functional teams that own 2-3 related services. Each team handles development, testing, deployment, and first-line operations for their services.

---

Action Plan

1. Apply DDD — Map your business domain into bounded contexts
2. Start monolithic — Build a well-structured monolith with clear module boundaries
3. Identify extraction candidates — Watch for modules that change independently or have different scaling needs
4. Extract one service at a time — Use the Strangler Fig pattern
5. Add infrastructure gradually — Containerization, CI/CD, service discovery as needed
6. Invest in observability — Centralized logging, metrics, and tracing before the second service is deployed
7. Establish contract tests — Prevent integration regressions
8. Review team structure — Align teams with service boundaries
9. Iterate — Boundaries will be wrong; expect to refactor
10. Never share databases — Protect independent deployability

Strengths

• Balanced perspective. Newman presents drawbacks alongside benefits honestly — the book makes a strong case for microservices while also warning against them when inappropriate. This credibility is rare in technical architecture books.
• Practical throughout. Every chapter includes concrete advice, configuration snippets, and real-world examples from ThoughtWorks projects. Abstract architectural principles are always grounded.
• Organizational insight. Part III (People) is the most distinctive section. Few technical architecture books address team topology, Conway's Law, and organizational change with this depth.
• Holistic scope. Covers the entire lifecycle — decomposition, integration, data, deployment, testing, monitoring, security — in one coherent volume.
• Clear prose. Newman writes accessibly, avoiding unnecessary jargon. Complex distributed systems concepts are explained clearly.
• Second edition improvements. Significantly expanded coverage of Kubernetes, serverless, event-driven architectures, and security compared to the 2015 first edition.

---

Weaknesses

• Too long. At 612 pages, the book covers many topics superficially that have their own dedicated books (Kubernetes, CI/CD, monitoring). A tighter edit would improve signal-to-noise ratio.
• Rapid aging in operations chapters. The deployment, monitoring, and CI/CD sections reference specific tools and versions that already feel dated (the Kubernetes ecosystem evolves quickly). These chapters will need another update within a few years.
• Limited distributed systems theory. Newman explains what to do but not deeply why. The CAP theorem, consensus algorithms (Raft, Paxos), and formal consistency models receive minimal treatment.
• Light on security. Security gets a single chapter. In practice, securing microservices (mTLS, JWT validation, API gateway policies, secret management) is a major undertaking.
• Opinionated without always acknowledging alternatives. Newman strongly prefers REST, Kubernetes, and certain patterns. Other valid approaches (GraphQL, service meshes, Dapr) receive less attention.

---

Criticism

The Distributed Monolith Problem

The book warns against distributed monoliths (services deployed separately but tightly coupled), but the guidance is easier to state than to follow. Many teams read this book and still end up with a distributed monolith because:

• Service boundaries are genuinely hard to get right
• Organizational pressures push teams toward coupling
• The book's decomposition heuristics are useful but underdetermined

Industry Backlash

By 2022-2023, a significant industry backlash against microservices emerged, with Amazon Prime Video and other high-profile teams publicly retreating from microservice architectures. Critics argue that the book understates the operational complexity. Newman's response (in the second edition) of "start monolithic, then split" is his hedge, but many readers skip this advice.

Theory Deficit

Software engineering faculty often note that the book lacks formal foundations. A student who reads this book without Kleppmann's will understand patterns but not principles — they can build a microservice system but cannot reason rigorously about its behavior under partition.

---

Counterarguments

| Criticism | Response | |-----------|----------| | "It's too long" | The length reflects the breadth of the topic. Skippable sections are clearly marked. | | "Ops chapters age fast" | The principles (CI/CD, observability pillars, deployment strategies) age well even if tool references do not. | | "Not enough theory" | The book is explicitly a practical guide, not a theory text. Complement with Kleppmann for theory. | | "Encourages premature microservices" | The second edition strongly emphasizes starting monolithic. The criticism applies more to the first edition. | | "Security is thin" | Security is a separate specialty; a single chapter is appropriate for an overview. | | "Microservices are overhyped" | Newman acknowledges this directly. The book is a field guide for those who have already decided to explore the pattern. |

---

Scientific Grounding

| Concept | Source | How the Book Uses It | |---------|--------|----------------------| | Conway's Law | Melvin Conway (1968) | Central organizing principle for aligning teams with architecture | | Bounded Context | Eric Evans, Domain-Driven Design (2003) | Primary heuristic for service decomposition | | CAP Theorem | Eric Brewer (2000) | Referenced, but not deeply explored | | Sagas | Hector Garcia-Molina (1987) | Foundation for distributed transaction management | | Strangler Fig Pattern | Martin Fowler (2004) | Migration strategy from monolith to microservices |

---

Historical Context

The first edition (2015) captured a pivotal moment. Netflix, Amazon, and Spotify had publicly described their microservice architectures, and the industry was eager to follow. Newman provided the first comprehensive how-to guide at exactly the right time.

Between editions (2015-2021), the ecosystem matured enormously: Kubernetes won the container orchestration war, serverless emerged as a viable deployment model, and service meshes (Istio, Linkerd) changed how services communicate. The second edition reflects this maturation.

By 2026, microservices are no longer controversial — they are a standard tool in the architect's toolbox, used where appropriate and avoided where not. This normalization is partly due to this book's sober, balanced treatment.

---

Comparison to Similar Books

| Book | Author | Key Difference | |------|--------|----------------| | Building Microservices | Sam Newman | The comprehensive field guide. Covers everything. | | Designing Data-Intensive Applications | Martin Kleppmann | Deep theory (consistency, replication, partitioning). No deployment or organizational guidance. | | Monolith to Microservices | Sam Newman | Focused solely on the migration journey. Shorter, more targeted. | | Fundamentals of Software Architecture | Mark Richards & Neal Ford | Broader architecture scope with a shorter microservices section. | | Microservices Patterns | Chris Richardson | Pattern catalog approach; more code-heavy, less organizational depth. |

---

Final Assessment

| Dimension | Rating | Notes | |-----------|--------|-------| | Practical Utility | 9/10 | The most hands-on, comprehensive microservices guide available | | Originality | 7/10 | Synthesizes existing patterns; organizational insight is original | | Readability | 8/10 | Clear, well-structured, accessible prose | | Depth | 7/10 | Broad rather than deep; theory readers need a companion volume | | Lasting Impact | 8/10 | Shaped how an entire generation of architects approaches distributed systems | | Overall | 8/10 | Essential for practitioners, but must be complemented with theory |

flowchart LR
    subgraph Monolith["Monolith"]
        M["All-in-one application"]
    end

    subgraph Decomposed["Microservices"]
        O["Orders Service"]
        P["Payments Service"]
        I["Inventory Service"]
        S["Shipping Service"]
    end

    M -->|"Step 1: Identify bounded contexts"| Decomposed
    O -.->|"Asynchronous events via Kafka"| P
    P -.-> I
    I -.-> S