Microservices architecture has become almost synonymous with "modern" software. Any mention of scalability, independence, or resilience seems to lead directly to decomposing everything into small services. But this reputation hides a more nuanced truth: microservices come with significant costs, and not every context justifies paying them.
What Are Microservices?
Microservices is an architectural style where an application is broken down into small, independently deployable services, each responsible for a specific business domain. Each service has its own process, communicates through APIs or messaging, and can be developed, deployed, and scaled independently.
The contrast is the monolith: a single application where all components share the same process, database, and deployment.
When Microservices Make Sense
Large Teams with Organizational Autonomy
The original motivation behind microservices was organizational, not just technical. When teams are large and independent, a shared monolith creates bottlenecks — a change in one module requires coordination with all others, deployments become risky, and the testing cycle grows.
Microservices make sense when you have teams of 8+ people working on different domains, and organizational independence between these teams is more valuable than the operational simplicity of a single application.
Drastically Different Scalability Requirements
If one part of your system needs to scale 50x independently of the others — a processing engine, a notifications service, a real-time stream — microservices allow you to scale exactly what needs to scale, without inflating the cost of the rest.
Heterogeneous Technology Requirements
When different parts of the system genuinely benefit from different technologies — an ML component in Python, a real-time interface in Node.js, a financial backend in Java — microservices allow each team to choose the best tool for their problem.
Clear and Stable Domain Boundaries
Microservices work well when business domains are well-defined and unlikely to change. Services that frequently need to be split or merged generate more operational cost than they save in autonomy.
When Microservices Are the Wrong Choice
Early-Stage Products
In the first months of a product, requirements change constantly. Domain boundaries that seem obvious today may prove wrong tomorrow. A monolith allows you to refactor without the overhead of inter-service communication, distributed deployments, and orchestration.
Amazon, Netflix, and Uber — frequently cited as microservices references — started as monoliths. They only migrated when complexity and scale genuinely demanded it.
Small Teams
Microservices transfer organizational complexity to the infrastructure layer. If you have a team of 3-5 people, they will spend more time managing services than building product features. The productivity cost is rarely worth it at this scale.
Systems Without Observability Infrastructure
Running microservices without robust observability — distributed tracing, centralized logs, health dashboards — is operating blind. Debugging an issue across a dozen services without the right tooling is orders of magnitude harder than in a monolith.
The Practical Alternative: The Modular Monolith
Between "everything in one file" and "everything in separate services" lies a sweet spot that many teams ignore: the modular monolith.
A modular monolith is a single application organized with strict boundaries between modules, well-defined internal contracts, and isolation that allows evolution — or future migration to microservices — without the current operational overhead.
This is often the right answer for products in growth phases that need agility today without sacrificing the option to scale architecture tomorrow.
Conclusion
Microservices are a powerful tool for specific problems. Adopting them prematurely or by trend rather than necessity generally results in unnecessary complexity, slowed delivery, and a distributed system that's harder to operate than the monolith it replaced.
Before deciding, ask: do we have the organizational problem microservices were designed to solve? If the answer is no, a well-structured modular monolith will likely serve you better.
Thinking about your system's architecture? Talk to our engineers.