The microservices mental model
Microservices are independently changeable business capabilities connected by a network, not merely a monolith split into many repositories.
Start with the organisational problem
A microservice architecture is useful when teams need to change different parts of a large product independently. The goal is not to maximise the number of deployables. The goal is to reduce coordination around well-understood business capabilities.
A modular monolith is usually the safer beginning. It keeps calls local, transactions straightforward, and debugging in one process. Move to services when ownership, scaling, isolation, or release cadence creates a measurable constraint—not because a diagram with many boxes looks mature.
What makes a service genuinely independent
A useful service owns a coherent capability, its implementation, and the data needed to make its decisions. Other services depend on a published contract rather than reaching into its tables or internal modules.
Independent deployment does not mean careless deployment. Contracts still need compatibility, telemetry, and a migration story. Independence means a service can evolve safely without requiring a coordinated release of every consumer.
- One accountable owning team
- A business-oriented boundary
- A versioned public contract
- Private implementation and data
- Independent build, test, deployment, and rollback
- Clear reliability expectations
The distributed-systems tax
A function call becomes a network request that can be slow, duplicated, reordered, or unavailable. A database transaction becomes a workflow across independently failing components. Logs scatter across processes. Local development needs more infrastructure.
Budget for service discovery, authentication, retries, timeouts, tracing, deployment automation, schema evolution, and on-call ownership. These are not optional platform polish; they are part of the architecture.
From product request to service response
A practical adoption test
- Can you name the capability without mentioning a technical layer?
- Can one team own its behaviour and production health?
- Does independent scaling or delivery solve a current problem?
- Can its contract remain smaller and more stable than its internals?
- Can you operate it when dependencies are unavailable?
Can you explain “The microservices mental model” without reaching for the API reference?
Describe the main trade-off, one failure mode, and the decision you would make in a real project.