Building Microservices runs to 616 pages. FDEs need five chapters

The second edition of Sam Newman’s Building Microservices runs to about 616 pages across 16 chapters. An FDE about to connect a product to a client’s system of dozens of services has no time to read it all before the kickoff meeting. To start reading someone else’s system, though, five chapters read closely are enough.

Most of the book is written for people who build microservices. An FDE’s job is usually to read and connect to a system someone else has built, sometimes badly. Read the right chapters and you gain the vocabulary and a few rules that speed up diagnosis, starting in your first week on site.

What changed in the second edition, and how far can it be trusted?

Newman says the second edition is a complete rework: every page of the first edition was reviewed and rewritten where needed. The original ideas remain, but most of the prose is new.

He also spends more time on the impact of containers, Kubernetes and serverless. The page for Helion, which resells O’Reilly Media’s ebook, also lists new material on user interfaces, container orchestration and security.

The book has three parts. Part I, Foundation, covers chapters 1 to 4: what microservices are, how to model services, how to split a monolith and the styles of communication between services.

Part II, Implementation, covers chapters 5 to 13: communication, workflow, build, deployment, testing, observability, security, resiliency and scaling. Part III, People, deals with user interfaces, organisational structure and the role of the evolutionary architect, who helps an architecture change gradually over time.

Nor does the book paint microservices in a rosy light. One practitioner’s review notes that it shows microservices are no silver bullet and come with drawbacks of their own.

As early as 2015, Newman wrote on his blog that getting service boundaries wrong can be costly. That caution suits FDEs well, because you will often meet systems whose boundaries were drawn wrongly.

Chapters 4 and 12: why is a slow service more dangerous than a dead one?

Start with chapter 4. Dan Lebrero’s notes on the chapter draw out one rule: with blocking synchronous communication, beware long call chains. The companion rule is to put logic in the endpoints, not in the middleware.

Picture the checkout flow of a retail client. Checkout calls inventory, inventory calls pricing, pricing calls payment, and every call is synchronous. If each service takes 50 ms, the whole chain takes 200 ms. But if pricing hangs for 3 seconds and nobody has set a timeout, every request upstream holds its connection and waits.

Chapter 12 names the phenomenon. According to Lebrero’s notes, very slow responses are one of the worst kinds of failure you can face. A service that is down reports an error at once. A slow service quietly drains the resources of everything calling it.

On a client site, the first thing to do is redraw the call chain for the exact flow your product will touch. Then ask them what the timeout is on each hop.

Chapter 5: contracts and duplicate messages

Chapter 5 is the one you will use most when writing integration code. Lebrero’s notes sum up two pieces of advice: use schemas to catch structural breaking changes, and avoid deployments that require both sides to release at the same time.

For an FDE, that means asking early for the schema files of the client’s API, then running automated checks against them, rather than guessing the data structure from a few sample responses.

The next piece of advice is harder to spot. Guaranteed message delivery is subtle, and it is best to assume duplicate messages will arrive. Imagine one of your agents listening for an “order paid” event in order to send a confirmation email.

If the broker delivers that event twice, the client’s customer gets two emails or, worse, is credited loyalty points twice. The fix is to attach an idempotency key and check it before performing the action.

Chapters 10 and 2: diagnosing a system that isn’t yours

Chapter 10 renames monitoring as observability. According to Lebrero’s notes on the chapter, observability is the extent to which you can understand a system’s internal state from what it emits externally.

When debugging someone else’s system, you cannot read all the code. Logs, metrics and traces are all you have, so ask the client whether they have distributed tracing before promising a deadline for a fix.

Chapter 2 offers a simple boundary test, and Lebrero’s notes show the idea recurs in chapter 7: if you constantly have to change several services at once, the boundaries are wrong.

On site, ask how many repositories a recent feature had to touch. The answer tells you where your integration will meet friction.

The three easiest mistakes when connecting to a client system

The first is trusting a few sample responses over the schema. Samples only show what the data looks like today; when the client changes a field, the integration code breaks without warning, whereas a check against the schema would have caught the change.

The second is assuming each message arrives exactly once. The chapter 5 notes already warn that message delivery is subtle, so every handler that receives an event or webhook should be written as if the same message will come back.

The third is making synchronous calls to the client’s services without a timeout. As in the checkout example above, your own call can become one more hop in the chain of waiting.

Who should read it, and in what order?

If you are comfortable writing APIs but have not yet had to debug a large distributed system, these five chapters are the shortest way in. Read chapter 4, then 5, 12, 10 and finally chapter 2.

Part III can wait until you lead an entire engagement. The practitioner’s review picks chapters 2, 6, 9 and 10 as the best, so chapter 6 on workflow and chapter 9 on testing are sensible next reads after the five above.

The same reviewer cautions that finishing the book does not leave you fully ready to build and run microservices in production. So once you have read it, do something concrete and write it down. On your CV, do not just write “experience with distributed systems”.

Write that you redrew the call chain in a client’s system, set timeouts on the calls and added idempotency to an event-driven integration. When an FDE job ad mentions integration or observability, put those lines at the top.

These five chapters will not make you a microservices architect. They help you do what clients need from an FDE in the first week: show where their system can fail, before it actually does.