CH10-01: Microservices Architecture Mental Model

Goal

Chapter 9 treated APIs as product and platform contracts. Microservices take that idea further: they ask whether parts of the system should be owned, changed, deployed, scaled, and operated independently.

Microservices architecture is not mainly about having many containers. It is an architecture pattern for separating business capabilities into services with clear contracts, data boundaries, and operational ownership.

The durable idea for this chapter is:

Microservices are useful when boundaries, ownership, data, communication, and operations can be made independent enough to justify the complexity.

This section helps you decide whether the pattern fits before you choose Azure Container Apps, Azure Kubernetes Service, Service Bus, API Management, or any other platform service.

The Short Version

The simple question is:

Should we use microservices?

The better architecture question is:

Which parts of the system need independent ownership, change, deployment, data, scaling, and operations?

A microservice should usually represent a business capability, not a technical layer. Catalog, orders, payments, inventory, fulfillment, and recommendations are possible business capabilities in a commerce platform. Controllers, repositories, helper libraries, and database tables are usually implementation details, not service boundaries by themselves.

Containers often appear in microservice designs because they package services consistently. But containers do not create microservices. A single tightly coupled application split into twenty containers can still behave like one fragile application if every change requires coordinated releases, shared database changes, and cross-team approvals.

The Independence Test

Use this mental model before splitting a system:

Business capability
  -> Service boundary
  -> Team owner
  -> API or event contract
  -> Owned data and operations

A candidate microservice is stronger when it can answer these questions clearly:

Question	Why It Matters
What business capability does it own?	Prevents splitting by technical layer only.
Which team owns it?	Makes decisions, incidents, and roadmap responsibility visible.
What contract does it expose?	Keeps other services from depending on internal code or tables.
What data does it own?	Avoids hidden coupling through a shared database.
Can it deploy independently?	Makes separation operationally useful, not decorative.
Can it fail without taking down everything?	Turns separation into resilience rather than more failure paths.

If these answers are weak, the design may not be ready for microservices. A modular monolith can still be a strong architecture when the team needs clear internal modules but not independent runtime ownership yet.

Microservices Versus a Modular Monolith

A modular monolith is one deployable application with disciplined internal boundaries. It can have separate modules for catalog, orders, payments, and inventory while still sharing one deployment pipeline and runtime.

That is not a failure. It can be the better first design when the product is young, the team is small, the domain boundaries are still changing, or operational maturity is limited.

Microservices become more attractive when the pain is specifically about independence:

Pressure	Why Microservices May Help
Different teams need separate release cycles.	Services can deploy without waiting for one large release train.
Different capabilities scale differently.	Checkout, search, and recommendations can scale independently.
Failure should be contained.	A recommendation failure should not stop payment capture.
Data ownership needs clearer accountability.	Payment, order, and inventory data can have distinct owners and controls.
The organization can support platform operations.	Teams can handle monitoring, incidents, security, and deployment discipline.

Microservices are less attractive when the main goal is novelty, resume value, or an assumption that small services are automatically simpler. They are simpler inside each service, but the whole system becomes more distributed.

Example: Commerce Platform Boundaries

Imagine a commerce platform that currently runs as one application. The catalog changes often because merchandisers add products and pricing rules. Orders need high reliability during checkout. Payments require strict security and partner integration. Recommendations change frequently but should not block a customer from buying.

A microservices conversation should not begin with:

How many containers do we need?

It should begin with:

Which business capabilities need independent ownership and failure behavior?

Orders and payments may deserve stronger separation because they have different risk, reliability, and ownership needs. Recommendations may also be separate because it can change frequently and degrade gracefully. A small admin back-office module might remain inside a modular application if it has low change pressure and one team owns it comfortably.

That is a healthy outcome. Microservices architecture does not require every module to become a service on day one.

Common Mistakes

Splitting code by technical layer, such as API, business logic, and data access, instead of by business capability.
Creating many services without independent team ownership or independent deployment.
Calling a design microservices while every service shares the same database tables.
Assuming containers, Kubernetes, or an API gateway automatically create service independence.
Moving too early to microservices before the team can operate distributed logs, traces, alerts, retries, and incidents.

If Someone Asks You

When should a team consider microservices?

A good answer is:

I consider microservices when parts of the system need meaningful independence: separate business ownership, separate release cycles, separate data responsibility, different scaling needs, or isolated failure behavior. I do not start with containers or Kubernetes. I start by checking whether the boundary, contract, data, team, and operations can be owned independently. If not, a modular monolith may be the safer design.

What You Should Remember

Microservices should buy meaningful independence, not just more deployment units.

Questions to Check Understanding

What must be independent for microservices to help?
Why are containers not enough to create microservices?
When might a modular monolith be safer?