Building Microservices

Synopsis

Building Microservices is a practical guide to designing, building, and operating microservice architectures. Sam Newman (formerly of Thoughtworks) covers the full lifecycle: modelling services, integration (synchronous and asynchronous), deployment, testing, monitoring, and security—with enough depth to make decisions without prescribing a single stack.

The book addresses the trade-offs that matter: when microservices help and when they don't, how to define boundaries, how to handle data and consistency, and how to evolve systems over time. The second edition updates the material for current tooling and patterns while keeping the focus on principles.

Why I Recommend It

It's one of the most balanced introductions to microservices. Newman is clear that microservices are an option, not a default, and that many organisations are better served by a well-modularised monolith first. The book helps you decide, then execute: service boundaries, API design, deployment, and observability.

Key takeaways:

• Bounded contexts: Service boundaries should align with business capabilities and team ownership
• Integration complexity: Communication, failure handling, and data consistency are the hard parts—not the code inside a service
• Evolution over big-bang: Strangler fig and incremental migration are safer than rewrites

Practical application: I've used it when designing or reviewing distributed systems and when discussing "should we split this into microservices?" The modelling and integration chapters give a shared language for talking about coupling, cohesion, and failure modes. The deployment and testing sections are useful for platform and SRE work.

For anyone building or operating distributed systems, it's a go-to reference.

Favourite Quote

"Start with a monolith, but keep the modularity. You can always break it apart later if you need to."

Newman repeatedly cautions against adopting microservices too early. The advice to begin with a well-structured system and split when boundaries and team needs are clear has saved many teams from unnecessary complexity.