Architecture debates often frame monoliths as outdated and microservices as modern. In practice both are valid tools, and the better choice depends on team size, domain clarity and operational maturity.
The case for a modular monolith
- One codebase, one deployment, one place to debug
- Refactoring across boundaries is a code change, not a coordinated release
- Transactions and data consistency are simpler
A modular monolith keeps clear internal boundaries — separate modules with defined interfaces — so it can be split later if needed.
When microservices earn their cost
- Several teams need to deploy independently without blocking each other
- Parts of the system have very different scaling or reliability needs
- Domain boundaries are well understood and stable
The hidden costs of distribution
Network failures
Every call between services can time out, fail or arrive twice. Retries, idempotency and circuit breakers stop being optional.
Data consistency
Each service owning its data means cross-service changes need patterns such as sagas or event-driven updates instead of a single transaction.
Observability
Following one request across many services requires distributed tracing, correlated logs and shared dashboards.
A simple rule of thumb
Start with a well-structured monolith. Extract a service when a specific, measurable pain — deploy contention, scaling, fault isolation — makes the extra complexity worth it.
- Architecture
- Microservices
- Scalability
