The microservices versus monolith debate has produced more bad architectural decisions than any other discussion in software engineering. Not because either answer is wrong, but because teams keep asking the wrong question. The question is not which architecture is better. It is which architecture is right for where you actually are.
The Microservices Mythology
Microservices became dominant in engineering culture during the era of Netflix, Uber, and Amazon — companies operating at massive scale with hundreds of engineers working on the same codebase. The architectural patterns they developed were responses to specific, extreme problems: the need for hundreds of independent teams to deploy without coordinating, the need to scale individual functions independently under variable load, and the need to isolate failures in systems with billions of users.
These are real problems. They are also problems that most organizations do not have. A company with 15 engineers does not have a coordination problem that justifies microservices overhead. A startup with 50,000 monthly active users does not have a scaling problem that requires independent service deployment. Yet both of these companies routinely choose microservices because microservices sound sophisticated and monoliths sound like legacy.
What a Monolith Actually Gives You
A well-structured monolith is simpler to develop, simpler to test, simpler to debug, and simpler to operate than an equivalent microservices architecture. Every distributed system introduces a category of problems that does not exist in a monolith: network latency, service discovery, distributed tracing, inter-service authentication, and the fundamental complexity of ensuring consistency across multiple independent processes.
“A modular monolith with clear domain boundaries will outperform a poorly-designed microservices architecture on every dimension that matters: delivery speed, system reliability, and engineering happiness.”
The Decision Framework
- Start with a monolith. Build it modularly with clear domain boundaries. Deploy it as a unit.
- Extract services when you have a specific, demonstrated need — not a theoretical one. Valid reasons: a specific module needs to scale independently, a specific team needs full deployment autonomy, or a specific function has security isolation requirements.
- Never extract a service because a technology trend says you should, or because a framework makes it easy.
When Microservices Make Sense
Microservices are the right choice when you have genuinely independent scaling requirements, multiple teams that need to deploy without coordination, or components with fundamentally different operational characteristics (a real-time processing engine versus a batch reporting system, for example). These conditions are real and common at scale. They are rare below it.
The Refactoring Myth
Many teams choose microservices because "we can always start with a monolith and break it apart later." This is theoretically true and practically very difficult. Breaking apart a monolith after it has accumulated business logic, tangled dependencies, and implicit coupling is one of the most expensive engineering projects an organization can undertake. The time to design for eventual decomposition is at the beginning — through clear internal boundaries — not after the coupling has been baked in.