Microservices Patterns, Mapped to the Problems They Fix

A microservice architecture builds one application as a set of small services. Each service runs in its own process, can be deployed on its own and talks to others over the network. If you are new to the idea, start with the microservices page. This page is about the patterns that come with it.

Splitting an application solves some problems, but it creates new ones. Calls that were function calls are now network calls, and the network can fail. Tables that were joined in one query now live in different databases. Clients need to know where dozens of services are. A pattern is a named, reusable answer to one of these problems.

The lesson's patterns slide makes one point clearly. These patterns do not exist in a monolith, because a monolith does not have these problems. Every pattern answers a specific pain of distributed systems, and no pattern works alone. Chris Richardson's pattern language at microservices.io groups them into areas such as decomposition, data management, external API, service discovery and reliability. The map below follows the same order a request takes.

The patterns serve a few principles. The lesson lists five:

• Single responsibility: each service does one thing well, so a change to billing does not affect search.
• Independent deployment: you can deploy one service without deploying the others.
• Data ownership: each service owns its own data store. No other service reads or writes it directly.
• Decentralized governance: teams choose their own tools, for example Python for machine learning and Go for networking.
• Design for failure: every network call can fail, so services must handle that with circuit breakers, retries and fallbacks.

The lesson says these look simple on paper and are the hardest part in practice. The moment two services share a database, data ownership is gone. The moment one service's deploy breaks another, independence is gone. A system that breaks these rules is called a distributed monolith: all the network costs of microservices with none of the benefits.

When service A calls service B and waits, a slow B makes A slow too. Chain several calls like this and one slow service can stall the whole request. The lesson describes this as cascading latency.

• Circuit breaker: after a set number of failures, stop calling the sick service for a while and return a fallback at once, such as cached data or a default. The trade-off is reduced function while the breaker is open, so you need sensible fallbacks.
• Bulkhead: give each dependency its own limited pool of threads or connections, so one slow dependency cannot use up everything.
• Retry with exponential backoff: try a failed call again, waiting longer each time. Retry only calls that are safe to repeat.

The Circuit Breaker Pattern lesson shows the three breaker states and how a breaker decides to try again.

Where to draw service boundaries is the biggest decision. The lesson gives two good ways. Split by business capability, meaning what the business does, such as orders, payments and inventory. Or split by subdomain, using domain-driven design to find bounded contexts. The wrong way is to split by technical layer, into a database service, a logic service and a UI service. That gives you a distributed monolith.

The lesson's sizing checks are practical. Can a team of 5 to 8 people own the service end to end? Can you explain what it does in one sentence? If changing one service always means changing another, they should be one service.

Few teams start from nothing. The strangler fig pattern moves a monolith one route at a time: new code takes over a feature while the old system still serves the rest. The Strangler Fig Pattern lesson shows how. A sidecar is a helper process deployed next to each service to handle shared jobs such as network traffic and telemetry, which is how a service mesh works.

Finally, the lesson is honest about cost. If you have fewer than 20 engineers and your monolith works, it advises you to keep it and structure it well. The patterns are answers to scaling problems you may not have yet. For the full picture, read the Microservices Architecture lesson, including how services talk to each other and the honest trade-offs table.