The Default Assumption
Somewhere in the last decade, "break the monolith" became the default recommendation for any system that had grown large enough to cause problems. The logic seemed sound: smaller services are easier to understand, easier to deploy, and easier to scale independently.
But the experience of actually decomposing monoliths tells a different story. Some decompositions produce dramatic improvements in delivery velocity and operational resilience. Others produce distributed monoliths: systems with all the operational complexity of microservices and none of the benefits.
The difference is not in the execution. It is in whether decomposition was the right choice in the first place.
When Decomposition Makes Sense
There are clear signals that suggest a monolith should be broken apart.
Deployment coupling is the primary bottleneck
If the reason you cannot release faster is that every change requires deploying the entire application, and different teams are constantly blocked by each other's changes, that is a strong signal. The goal is independent deployability, and if the monolith prevents it, decomposition addresses the root cause.
Different components have different scaling requirements
If your API gateway needs to handle 10x traffic during peak hours but your background processing can run at a constant rate, a monolith forces you to scale everything together. Decomposition lets you match compute resources to actual demand.
Organizational boundaries are clear
Conway's Law is real. If you have three teams that own distinct business domains, and those domains have clear boundaries, decomposition aligns the architecture with the organization. This reduces coordination overhead and lets each team make decisions independently.
Technology constraints are blocking progress
If part of your system needs a different runtime, a different data store, or a different deployment model, and the monolith prevents that, decomposition removes the constraint. This is particularly relevant when adopting new capabilities like ML model serving or event-driven processing.
When Decomposition Does Not Make Sense
The signals against decomposition are equally clear, but they are often ignored because the industry narrative favors microservices.
The team is small
A team of four engineers does not need twelve services. The coordination overhead of managing service boundaries, API contracts, deployment pipelines, and distributed debugging outweighs any benefit. Small teams are more productive with a well-structured monolith that they can deploy and reason about as a single unit.
The domain boundaries are unclear
If you cannot draw clear lines around the business capabilities, you are not ready to decompose. Premature decomposition creates services with the wrong boundaries, which leads to excessive inter-service communication, distributed transactions, and the eventual realization that you need to merge services back together.
The operational foundation is missing
Microservices require robust operational infrastructure: service discovery, distributed tracing, centralized logging, deployment automation, and circuit breakers. If your team does not have these capabilities, decomposition will create operational problems faster than it solves architectural ones.
The performance requirements do not justify the network overhead
Every service boundary introduces network latency. If your system requires sub-millisecond response times for operations that would cross service boundaries, the network overhead of microservices may be unacceptable. In-process communication is always faster than network communication.
The Decision Framework
When working with clients, we use a structured framework to evaluate whether decomposition is the right approach.
Step 1: Identify the constraint. What is the actual problem? Slow releases? Scaling limitations? Team coordination overhead? Technical debt? The constraint determines whether decomposition addresses the root cause or just moves the problem.
Step 2: Evaluate the alternatives. Could the same problem be solved with a better modular architecture within the monolith? With improved CI/CD practices? With better team organization? Decomposition is an expensive solution. Make sure cheaper solutions have been considered.
Step 3: Map the domain boundaries. If decomposition is warranted, use domain-driven design to identify bounded contexts. These become the candidate service boundaries. If the boundaries are clear and stable, decomposition is more likely to succeed.
Step 4: Assess operational readiness. Does the team have the infrastructure and skills to operate a distributed system? If not, plan for that investment as part of the decomposition program. The operational foundation needs to be in place before services are extracted.
Step 5: Start with one extraction. Do not decompose the entire monolith at once. Extract one service, operate it in production, and learn from the experience. This validates the approach, builds operational capability, and provides evidence for the business case.
The Honest Conversation
The hardest part of the monolith decision is the conversation with stakeholders. "We need to rewrite the system" is a difficult message to deliver, especially when the system is generating revenue. "We should keep the monolith and improve it" is equally difficult when the organization has already decided that microservices are the future.
The right answer requires honesty about the constraints, the costs, and the organizational capability. Decomposition is a multi-quarter investment that will slow feature delivery before it accelerates it. The organization needs to understand and accept that tradeoff.
When the signals are clear and the team is ready, decomposition produces dramatic improvements. When the signals are ambiguous or the team is unprepared, it produces expensive complexity. The framework exists to tell the difference.