When teams start getting in one another's way, microservices look like an obvious answer. Give each team a service and its own release cycle. Problem solved — except the organisation also inherits network failures, more deployments and a larger operational workload.
What if the application being in one piece is not the real problem? Perhaps the pieces inside it simply have no boundaries.
One application does not mean shared ownership of everything
Take an online store. Catalog, orders, payments and customer accounts remain in one application, typically built and deployed together. It is still a monolith.
The difference is that each area has rules of its own. Catalog code should not reach directly into payment tables; customer accounts should not depend on an order module's private implementation. They communicate through defined interfaces instead.
That is a modular monolith: one deployment with meaningful internal boundaries. Think of separate departments in the same building. Sharing an address does not mean everyone should walk straight through everybody else's walls.
Folders are not boundaries
Many systems look modular on a diagram. The code tells another story: anyone can import anything, read every table and bypass the intended API. The first exception is made for an urgent feature; the next becomes routine. Soon the diagram describes a system that no longer exists.
Real boundaries need enforcement. That can mean dependency rules, explicit module interfaces, ownership of data and automated architecture checks. A single physical database is possible, but another module's tables should not quietly become a public API.
Ownership matters too. If no team is accountable for a module's contract and its changes, splitting code into folders will not eliminate cross-team negotiations.
The business case for staying together
The advantage is not the label “modular.” A team can understand and modify one capability without needlessly disturbing others. Onboarding can become easier. Change can become more predictable — provided the boundaries are real.
The business also avoids paying upfront for independently deployed services, network contracts, cross-service failure handling and distributed data coordination. More engineering effort may remain available for the product itself.
But modularity is not the same as independent deployment. If the application ships as one unit, release coordination still exists. Slow tests and cumbersome approvals can hold everyone back. No module boundary will fix a broken delivery process.
The point where one runtime starts to hurt
Imagine that product recommendations begin consuming a disproportionate share of resources. When the calculation runs in the same process as checkout, the pressure can affect both. Extracting that workload might be justified.
Yet moving a module to a service is not a file-moving exercise. A local function call becomes a network interaction with timeouts, retries and partial failures. Data ownership and consistency rules may need redesign. A perfectly good in-process interface is not necessarily a good remote API.
So “we'll make it modular now and split it effortlessly later” is a risky promise. Good boundaries make extraction more manageable. They do not make it free.
Questions worth asking before a redesign
I would start with the actual source of delay. Do changes regularly cross several parts of the code? Then dependencies deserve attention. Are releases held up by testing and approval procedures? Fix the delivery process. Does one capability need distinct scaling, availability or ownership? Now there is a stronger case for a separate service.
Managers should ask about consequences, not module counts: which teams block each other, how long changes take to verify and ship, what happens when one component fails, and who owns each data boundary.
Sometimes the sensible decision is to keep the application together and improve its internal structure. Sometimes one carefully chosen extraction is enough.
Split a system when the cost of remaining together exceeds the cost of operating independently. Until then, teach its parts to respect their boundaries.
Related reading: why monoliths can be a rational choice and when microservices earn their cost.