Mapping the Knot: A Framework for Assessing Whether Your Monolith Can Actually Be Split

The decision to decompose a monolithic application is rarely made in a moment of calm deliberation. It is usually made in response to pressure—scaling problems, deployment bottlenecks, team coordination friction, or the accumulated frustration of working inside a codebase that has grown beyond anyone's ability to fully understand.

That pressure creates a bias toward action. The microservices architecture that solved someone else's problems at a conference talk last quarter becomes the obvious answer. The rewrite gets scoped. The migration roadmap gets drafted. And then, several months in, the team discovers what they should have assessed before they started: that the system is not merely large, it is deeply entangled—and that the seams everyone assumed existed do not, in fact, run where anyone thought they did.

This framework is designed to prevent that discovery from happening after the work has begun.

The Difference Between Difficult and Impossible

Not all monoliths are equally resistant to decomposition. Some are large but well-structured—they have clear module boundaries, minimal shared state, and data models that map cleanly onto distinct business domains. These systems are difficult to migrate, in the sense that any large technical undertaking is difficult, but they are not architecturally opposed to the effort.

Others are genuinely unmigrationable in their current form. Their shared state is pervasive. Their data models cross domain boundaries in ways that cannot be cleanly separated without either duplicating data, introducing synchronization complexity, or accepting consistency tradeoffs that the business cannot tolerate. Their business logic is distributed across layers in patterns that reflect years of pragmatic shortcuts rather than any coherent design intent.

The critical mistake is treating these two categories as though they differ only in degree. They differ in kind. The tools and strategies appropriate for a difficult migration are not appropriate for a genuinely entangled system—and applying them to the latter is how organizations end up with partially migrated architectures that are more expensive to operate and harder to reason about than the original monolith.

Step One: Map the Dependency Graph

The first step in any decomposition assessment is constructing an accurate dependency graph of the system's internal structure. This is distinct from reading the architecture documentation, which describes the system as it was intended to be built, not as it was actually built.

The dependency graph should capture three categories of coupling:

Data coupling describes the extent to which different functional areas of the system read from and write to shared database tables or schemas. A table that is written by five different modules and read by eight is a coupling hub—it cannot be assigned to a single service without making every other module dependent on that service.

Behavioral coupling describes the extent to which one module's execution depends on the internal state or side effects of another. This is frequently invisible in the codebase because it manifests as implicit ordering assumptions rather than explicit dependencies. A billing module that assumes a particular record state has been set by an upstream order module—without any formal contract between them—is behaviorally coupled in a way that will not survive a service boundary.

Temporal coupling describes the extent to which operations in different parts of the system must occur within a defined time relationship to produce correct results. Synchronous database transactions that span what would become multiple service boundaries are the most common form. Replacing them with asynchronous message-passing introduces eventual consistency—which may be acceptable in some contexts and catastrophic in others.

Step Two: Identify the Coupling Hubs

Once the dependency graph is mapped, the next step is identifying the coupling hubs—the nodes in the graph that have the highest number of inbound and outbound dependencies. These are the structural obstacles to decomposition.

A coupling hub is not necessarily a problem to be solved. It may be a problem to be acknowledged. Some hubs exist because the underlying business concept they represent is genuinely cross-cutting—it does not belong to a single domain because it is implicated in every domain. An identity model that threads through every functional area of an enterprise application is not poorly designed. It is accurately representing a business reality.

The practical implication is that coupling hubs of this type cannot be assigned to a microservice without making every other service dependent on that service. The alternative—duplicating the hub's data across multiple services and managing synchronization—introduces a different class of complexity that may be worse than the original coupling.

Identifying which hubs are architectural artifacts versus which are accurate representations of business reality is the single most important analytical step in a decomposition assessment.

Step Three: Assess Real vs. Perceived Separation of Concerns

Most monolithic systems have some degree of modular organization—packages, namespaces, or folder structures that suggest a separation of concerns. In practice, the actual separation is frequently much weaker than the organizational structure implies.

A useful diagnostic is to select a representative set of business operations—a checkout flow, a user registration sequence, an order fulfillment process—and trace the complete execution path of each through the codebase. Count the number of distinct modules touched. Map the data entities read and written. Note every place where the operation crosses what would be a service boundary in a decomposed architecture.

This exercise consistently surfaces two findings. First, the number of modules involved in a single business operation is almost always larger than anyone estimated. Second, the data access patterns almost always violate the domain boundaries that the modular structure implies.

These findings are not arguments against decomposition. They are inputs to a realistic assessment of what decomposition would actually require.

Step Four: Determine the Right Path Forward

With an accurate dependency graph, identified coupling hubs, and a realistic picture of separation-of-concern violations, engineering leaders are equipped to make an informed decision between three paths.

Incremental modernization is appropriate when the coupling is concentrated in a small number of hubs and the majority of the system has genuine domain boundaries that can be enforced through refactoring before extraction. The strangler fig pattern—gradually replacing portions of the monolith with new services while the original system continues to operate—is the most reliable approach in this scenario.

Strategic consolidation is appropriate when the analysis reveals that the perceived domain boundaries do not reflect the actual business logic—that what was assumed to be two separable concerns is, in fact, one concern that was artificially divided. In these cases, consolidating the relevant modules and clarifying their shared data model is more valuable than attempting to enforce a boundary that the business logic does not support.

Deferred decomposition is appropriate when the coupling is pervasive and the system is stable. The cost of decomposition—in engineering time, operational complexity, and risk—must be weighed against the cost of the current architecture. For systems that are not experiencing the scaling or deployment problems that microservices are designed to solve, the honest answer may be that decomposition is not the right investment at this time.

The Value of an Honest Assessment

The framework described here will not always produce the answer that stakeholders want to hear. A rigorous mapping exercise may reveal that a migration that was scoped for eighteen months requires thirty-six—or that it requires a different approach entirely.

That finding is valuable. It is far less costly to discover the true complexity of a system before committing to a decomposition strategy than to discover it after six months of migration work have produced a partially split architecture that is harder to operate than what it replaced.

At SE Projects, the most technically sound decisions we have observed are the ones made with the most complete information—including complete information about what a system cannot easily become.