The microservices-vs-monolith debate is often framed as a binary choice, but the honest answer is that most applications should start monolithic, and the trade-offs of splitting apart are more costly than the marketing around microservices tends to admit.
What a Monolith Gets Right
- Simple deployment — one artifact, one place to look for logs, one transaction boundary
- Refactoring across module boundaries is a normal code change, not a coordinated multi-service rollout
- No network calls between components that used to be simple function calls — genuinely faster and more reliable
When Microservices Genuinely Pay Off
- Multiple teams need to deploy independently without blocking each other
- Different components have genuinely different scaling needs (a video encoding service vs a simple CRUD API)
- You need to use different languages/runtimes for different parts of the system
The real cost microservices introduce — network reliability, distributed tracing, eventual consistency, deployment orchestration — is substantial, and it’s a cost worth paying only once monolithic simplicity is genuinely the bottleneck, not before. “Start with a monolith, extract services when you actually feel the pain” remains solid, well-tested advice.