Microservices have become the default choice for many teams building new systems. But the decision to adopt a distributed architecture should be driven by concrete requirements, not by what is fashionable.
When microservices make sense
Microservices are a good fit when:
- Different parts of the system need to scale independently. If your payment processing needs 100 instances but your user management needs only 2, separating them saves resources.
- Teams need to work independently. Large teams working on the same codebase create coordination overhead. Clear service boundaries let teams own their domain end-to-end.
- Different deployment cadences. If your reporting service can be deployed once a month but your API needs daily releases, separate services avoid friction.
- Technology diversity is justified. When a specific service genuinely benefits from a different language or data store, microservices make that possible.
When a modular monolith is better
A modular monolith is often the right starting point:
- Your team is small. A monolith means one deployable unit, simpler development environment, and no network failures between services.
- The domain is tightly coupled. If most operations touch multiple entities, splitting them into services adds latency and complexity without benefit.
- You are still learning the domain. Monoliths are easier to refactor. Extract services once you understand the boundaries.
- Operational maturity is low. Running microservices requires solid CI/CD, observability, and incident response. Without these, a monolith is more reliable.
The pragmatic path
Start with a modular monolith. Define clear module boundaries with well-defined interfaces. Add monitoring and CI/CD. When a module consistently needs independent scaling, different deployment frequency, or a separate team, extract it into a service.
The goal is not to have microservices. The goal is to have a system that is easy to change, operate, and scale. Sometimes that is a monolith. Sometimes it is microservices. Often it is somewhere in between.