Building Microservices

What the book covers

The second edition is a thorough rewrite of the popular first edition. According to the author's site, every page was reviewed and reworked where needed, and new topics were added to reflect how microservices practice changed, including containers, Kubernetes and serverless. It has 16 chapters in three parts:

• Foundation: what microservices are, how to model them (with domain driven design), how to split a monolith, and communication styles.
• Implementation: implementing communication (now three chapters on inter process communication), workflow, build, deployment, testing, observability, security, resiliency and scaling.
• People: user interfaces, organisational structures and the evolutionary architect.

Chapter 1 is available as a free download from the author's site, which is a good way to judge the writing before buying.

Why it is respected

It is honest. Newman repeatedly argues that microservices are not a default and that many teams should not split yet. The chapters on breaking apart a shared database and on the organisational cost of services cover the parts teams most often underestimate. Reviewers on Goodreads consistently mention its balance and practicality; the first edition averages about 4.22 out of 5 from over 5,000 ratings (September 2026).

When to read it

Read it after you have felt the pain of a large single codebase or worked on a system with several services, not before. Without that experience, the trade offs can feel abstract. It is especially valuable:

• when your team is debating a move to microservices;
• when you have services that are hard to deploy independently;
• when you are becoming a tech lead responsible for service boundaries.

How to read it

• Read the Foundation part fully; it shapes how you judge everything else.
• Treat the Implementation chapters as reference and read the ones relevant to your current problems.
• Do not skip the People part. Conway's law (systems mirror the communication structure of the organisation) explains many failed migrations.
• If you are splitting a monolith, read Newman's companion book, Monolith to Microservices, which goes deeper into migration patterns.

Weak spots

• Mostly technology neutral, so you will not find step by step code for a specific framework.
• Long. Reading cover to cover takes several weeks for most people.
• Some readers want more worked examples of complete systems.

Pair it with

• Software Architecture: The Hard Parts for detailed trade off analysis on data and workflows.
• Microsoft's cloud design patterns for quick reference on saga, circuit breaker and gateway patterns.
• Martin Fowler's microservices guide for the original articles and the "monolith first" argument.

Best for: engineers and tech leads working with service based systems who want balanced, practical guidance on when and how to use microservices.