Chapter 5 is the book's warning label. Once the first services are live, a new set of problems arrives, and they do not arrive all at once. Newman walks through ten of them: for each, how it tends to show itself, roughly when it hits, and where to start fixing it. He is open that he cannot solve them all in one chapter and points to Building Microservices for depth, so this chapter works best as a checklist you return to as your system grows.

Most of these pains land on ordinary developers first: a broken consumer after a deploy, a laptop that cannot run the system, an end-to-end suite nobody trusts. A two-page coda then restates the book's two messages.

Chapter 5 and the closing words in chapter 6.

Key ideas

A dial, not a switch

The framing idea is that adopting microservices is like turning a dial. Each extra service gives you more of the benefits and more exposure to new problems. Newman's observation is that the problems a company with ten services faces are quite different from those of a company with hundreds, so the number of logical services is a reasonable rough signal for which pains are coming next. He is careful to call this anecdotal. The variable he singles out is coupling: a tightly coupled architecture meets robustness, testing and tracing problems earlier than a loosely coupled one.

My own summary of the ten problems, drawn from what the chapter says about each:

Problem How it shows up When the book expects it
Ownership at scale Nobody steers a service; point-to-point calls everywhere Fast growth, roughly beyond 20 co-located developers
Breaking changes Outages right after a deploy; lock-step releases Early, once more than one team is involved
Reporting Analysts lose their single SQL database Early, when you start splitting the schema
Monitoring and troubleshooting Unexplained failures, alerts while things look healthy Hard to predict: a few services or twenty
Local developer experience Slow local runs, requests for bigger laptops Depends on service count and runtime footprint
Running too many things More time on deploys, manual mistakes As services and instances multiply
End-to-end testing Slow, flaky suites; pressure for a test team When journeys cross several teams
Global vs local optimisation Teams solve the same problem differently Multi-team organisations, after a period of scaling
Robustness and resiliency Rare failures become routine As the number of services and calls grows
Orphaned services Nobody knows what a service does or who owns it After years of running microservices

The chapter's closing point is about balance: you cannot see the future, so watch for the signals above, but do not spend months fixing problems you may never have.

People and structure: ownership, global vs local, orphans

Ownership at scale. The book uses Martin Fowler's three models: strong ownership (owners approve outside changes), weak ownership (anyone can change code but talks to the owner first) and collective ownership (anyone changes anything). Collective ownership needs a shared sense of what a good change looks like. Newman is comfortable with it for a small co-located group of around 20 developers, but it breaks down under fast hiring. His example is a fintech that grew from around 30 or 40 developers to more than 100 without assigned ownership and ended up with a tangled distributed monolith. The remedy he sees at nearly every large microservice organisation is strong ownership per team, with each team practising collective ownership internally. It also lets teams align with a business area.

Global versus local optimisation. Autonomy produces locally sensible choices that add up badly: one team picks one database, another picks a different one, and the organisation now maintains skills and licences for three. You usually discover this by accident. The remedy reuses chapter 2's idea of reversible and irreversible decisions: teams decide reversible things locally and pull in others for expensive, hard-to-undo ones. Mechanisms include a cross-team technical group with a lead from every team, or a lighter culture of written proposals that anyone can comment on, as the book describes at Monzo.

Orphaned services. Independent deployability means some services run untouched for years. Eventually nobody remembers what they do, people are afraid to change them, and some teams cannot even find the source code. The remedy is a registry of what runs and who owns it, built from metadata in repositories and data from service discovery. The book's richest example is the Financial Times' Biz Ops tool, which also scores how operable each service is. When you find an orphan, give it an owner (with strong ownership) or schedule work to bring it up to standard.

Contracts and testing: breaking changes, end-to-end tests

Breaking changes. Every service has a contract with its consumers, explicit or not, covering both structure and behaviour. Newman's practical rules are: eliminate accidental breaks, think twice before a deliberate one, and give consumers time to migrate. For accidental structural breaks he favours explicit schemas that make contract changes visible, even tools that refuse incompatible changes. For deliberate changes, prefer expansion: add a field or endpoint instead of changing one. When you must break, he prefers one service that serves both the old and new contract over running two versions side by side, which needs more infrastructure and bug fixes in two branches. In TypeScript terms, an expansion change looks like this:

type CourseSummaryV1 = {
  id: string;
  title: string;
  priceVnd: number;
};

type CourseSummary = CourseSummaryV1 & {
  price: { amount: number; currency: "VND" | "USD" };
};

export function toCourseSummary(course: {
  id: string;
  title: string;
  priceAmount: number;
  priceCurrency: "VND" | "USD";
}): CourseSummary {
  return {
    id: course.id,
    title: course.title,
    priceVnd: course.priceCurrency === "VND" ? course.priceAmount : 0,
    price: { amount: course.priceAmount, currency: course.priceCurrency },
  };
}

Old consumers keep reading priceVnd, new ones read price, and the old field is removed only after consumers have moved. The chapter's sharpest line of argument is that organisations which never get this under control probably will not survive long enough to grow large.

End-to-end testing. As tests span more services, they get slower, flakier and harder to own, and people start rerunning failures until they pass. The remedies: keep multi-service tests inside the team that owns those services, use consumer-driven contracts so each consumer states its expectations as executable tests, invest in progressive delivery with automated rollback based on thresholds such as p95 latency and error rate, and keep pruning tests as well as adding them. Newman calls consumer-driven contracts an underused practice that some teams adopt with great success and others struggle with.

Seeing the system: monitoring and reporting

Monitoring and troubleshooting. A monolith tends to be up or down. A distributed system fails partially, and a single busy process may or may not matter. The signals are production issues nobody can explain, alerts while the system looks fine, and difficulty answering "is everything OK?". Newman's remedies, in the order he presents them:

  1. Log aggregation first. He treats it as the first thing to build, and as a readiness test: an organisation that struggles to set it up is probably not ready for microservices.
  2. Correlation IDs on every inbound call, ideally generated at the gateway or mesh, and passed along on every hop.
  3. Distributed tracing (he names Jaeger), sooner if you are latency sensitive.
  4. Testing in production with synthetic transactions, using fake accounts that cannot cause real effects.
  5. Observability: collecting enough data to answer questions you did not anticipate.

In 2026 the correlation ID usually travels as the W3C traceparent header that OpenTelemetry propagates for you:

gateway          traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
  -> enrollment  same trace id, new parent span id
    -> payment   same trace id, new parent span id
logs and spans from all three can be queried by trace id 4bf92f...

Reporting. Reporting users lose the single database they used to query, often with SQL tools tied to the old schema. This bites early, as soon as you start splitting data, and teams often notice halfway through. The remedy is a dedicated reporting database fed from the services through CDC, views, events or code, with its schema designed for reporting needs. If you already have a data warehouse, services just need to feed it.

Building and running: local development, too many things

Local developer experience. At some point a laptop cannot run every service. Newman notes he could run four or five JVM services locally, not twenty. The signals are slow local runs and requests for bigger machines. Teams with strong ownership of a few services suffer less, because they already stub what they do not own. The options are stubbing, developing against a remote environment (which needs connectivity and costs money), or hybrids like Telepresence (still a CNCF sandbox project in 2026) that run one service locally and proxy the rest to a cluster.

Running too many things. Manual deployment and older configuration management tools stop scaling as services and instances multiply, and more time goes to deploys and to fixing deploy mistakes. The remedy is a platform with desired state management and developer self-service. Newman names Kubernetes as the common choice but warns against adopting it before your current approach strains. On public cloud he describes his own default as serverless-first, using functions as a service where they fit.

Robustness, and the closing words

Robustness and resiliency. Rare failures (lost packets, timeouts, dead machines) become routine as calls multiply, and they mostly show up in production. Newman's starting point is two questions for every call: how can it fail, and what should we do when it does? Then come the patterns: asynchronous communication to reduce temporal coupling, time-outs, circuit breakers, multiple instances, and a platform that restarts what crashes. He also treats resilience as a way of working, and suggests recording what you learn from each production incident. A small sketch of answering both questions for one call:

type Recommendation = { courseId: string; title: string };

export async function fetchRecommendations(
  learnerId: string,
): Promise<Recommendation[]> {
  try {
    const response = await fetch(
      `https://recommendations.internal/learners/${learnerId}`,
      { signal: AbortSignal.timeout(800) },
    );
    if (!response.ok) return [];
    return (await response.json()) as Recommendation[];
  } catch {
    return [];
  }
}

The failure modes are a slow or failing service; the decision is that the course page renders without recommendations rather than waiting.

Closing words. The coda is two pages. Its first message: give yourself room to gather information and decide for your own context instead of copying others. Its second: adopt microservices and the related practices incrementally, in manageable steps you can adapt as you go. It ends by noting that microservices are not for everyone.

Reading it in 2026

Most of the chapter's remedies now have standard tools.

  • Observability. OpenTelemetry graduated in the CNCF in May 2026 and is the default way to instrument traces, metrics and logs. Correlation IDs, log aggregation and tracing are now one instrumentation layer, with the backend as a separate choice.
  • Contract testing. Pact is still the reference tool for consumer-driven contracts, and its broker's "can I deploy" check answers the breaking-changes question before a release. For schema-first APIs, breaking-change checkers for Protocol Buffers and OpenAPI play the role the book gives to protolock.
  • Platform engineering. Running too many things and local developer experience are now usually the job of an internal platform team offering self-service golden paths. The CNCF's platform engineering maturity model is a useful way to discuss where you are.
  • Service catalogues. Backstage, a CNCF incubating project, is a common base for the registry the book recommends against orphaned services, with ownership recorded as metadata next to the code.
  • Progressive delivery. Tools such as Argo Rollouts and Flagger automate the metric-gated rollouts and rollbacks the book describes.

Putting it to work

  1. Set up log aggregation and OpenTelemetry trace propagation before the second service goes live.
  2. Give every service one owning team and a catalogue entry, and review entries without an active owner every quarter.
  3. Make contracts explicit, run a breaking-change check in CI, and prefer expansion changes.
  4. Replace cross-team end-to-end tests with contract tests, and keep only a few journey tests owned by one team.
  5. Plan the reporting database before splitting the first schema, and agree it with the people who run reports.
  6. For every remote call, write down how it can fail and the fallback, and enforce a time-out.
  7. Keep a short list of decisions that need cross-team agreement (databases, languages, deployment platform), and leave the rest to teams.

Check yourself

  1. Why does Newman use the number of services as a signal? Because different problems tend to appear at different scales; he also notes that tighter coupling brings them on earlier.

  2. What should you build first when adopting microservices, according to the book? Log aggregation, which is both useful immediately and a test of whether the organisation is ready.

  3. Which way of supporting a breaking change does Newman prefer? One running service that exposes both the old and new contract, rather than two coexisting versions.

  4. What does the book suggest instead of large cross-team end-to-end tests? Team-scoped tests, consumer-driven contracts, progressive delivery with automated remediation, and continual pruning of tests.

  5. What two questions should you ask about every service call? How can this call fail, and what should we do when it does?

Further reading