The Monolith Factor (An Experiment in Measuring Architecture)

To begin with, an important disclaimer. What I present in this article is a conceptual model. It is not an objective or ultimate truth about system architecture. It is an experiment. An attempt to describe the concept of a ‘monolith’ in a numerical and more tangible way. The goal is not to perfectly reflect reality. The goal is to create a tool for thinking, discussion, and decision-making.

Problem

Discussions about architecture very often look similar:

‘This is a monolith’ ‘No, these are microservices’ ‘But you have a single database’

There is a lack of a common language. There is a lack of a point of reference. Opinions appear, but there is no way to compare them.

Idea

Instead of classifying a system as a monolith or microservices, let’s treat architecture as a spectrum.

We assume: M ∈ [0,1]

Where: M = 1 means a fully monolithic system (probably does not exist) M = 0 means a fully distributed system (does not exist) intermediate values describe hybrid systems

Formula

We describe the monolithicity of a system as a combination of four areas:

M = αA + βB + γC + δD Where: A represents code structure and dependencies B represents data and how it is stored C represents operations and deployment approach D represents runtime and communication

The weights α, β, γ, δ sum up to 1

Model assumptions

This model has several important properties that need to be clearly stated.

First, the scale from 0 to 1 is conventional. It does not perfectly reflect reality, and it does not have to. The values are an approximation that helps compare systems or track changes over time.

Second, the model is not universal. Individual elements may have different significance depending on the system. That is why different weights can be applied. In one system, data may be key, in another, the deployment approach.

For example: M = 0.5B + 0.2A + 0.2C + 0.1D

In this case, data has the greatest impact on the result.

Third, the result is not absolute. The same system evaluated by two teams may yield different values. This is not an error, but a consequence of simplification.

What can this be useful for?

The greatest value of this model is not the number itself, but the way it is used and the direction of change.

1) Tracking progress

The model works very well in the context of refactoring.

Instead of saying that the system “seems better,” you can observe changes in the value of M over time. Moving from 0.8 to 0.6 is a concrete indication of the direction of change.

2) Decision-making

Often, it is not possible to change everything at once.

If one factor is difficult to reduce, for example a shared database, the model allows you to look at other areas. You can identify elements that also strongly influence monolithicity and that can be changed more quickly.

This helps use time effectively.

3) Prioritization

Not all changes have the same impact.

The model makes it possible to identify which elements pull the system most strongly toward a monolith. This allows you to focus on actions that bring real value instead of cosmetic improvements.

4) Observations from practice

Many systems described as microservices still exhibit monolithic characteristics in reality.

For example:

1. a shared database
2. strong coupling between components
3. dependent deployments

In such cases, the value of M often remains high. This means that the architectural change was superficial.

Example: CRM with Nx workspace

Structure:

/apps
  /api-gateway
  /users-service
  /customers-service
  /orders-service
/libs
  /shared-dto
  /auth
  /messaging
/docker
  docker-compose.yml

1) How to read this

Nx acts here as an environment for distribution:

• each service is a separate application
• domain boundaries are visible
• it is possible to move toward microservices

2) What increases the “M” parameter

• a shared database (docker-compose)
• running everything together
• shared DTOs without versioning

Shared DTO is not a problem if:

• it is an API contract
• it is versioned

It is a problem if:

• it forces changes across multiple services
• it reflects the domain model

3) What decreases the “M” parameter

• services are physically separated (separate applications)
• communication can happen via HTTP or messaging
• domain boundaries exist (users, orders, customers)
• Nx enforces structure and dependency control

4) Evaluation

In a CRM system, we want data and operations to have the greatest importance, therefore:”

M = 0.4B + 0.3C + 0.2A + 0.1D

Example values: A = 0.5 (Nx reduces coupling, but shared libraries still exist) B = 0.9 (shared database) C = 0.7 (partial independence, but still shared runtime) D = 0.6 (network communication, but limited isolation)

Calculation: M = 0.4×0.9 + 0.3×0.7 + 0.2×0.5 + 0.1×0.6 M = 0.36 + 0.21 + 0.10 + 0.06 = 0.73

4) Conclusion

Nx helps to separate the system, but it does not do it automatically. If you cannot change the database, optimize other elements to realistically reduce M.

At the same time, it is worth remembering that reducing M is not always a goal in itself. The closer a system gets to being fully distributed, the more its complexity — and consequently the costs of maintenance, operations, and inter-service communication — may increase.

Therefore, architectural decisions should take into account not only M, but also maintenance cost. In practice, the best approach is to track both dimensions in parallel and look for a balance point, rather than striving for the lowest possible M at all costs.

Possible improvements to the model

The model can be developed in several directions.

Better input metrics Instead of estimating values, data from repositories, monitoring systems, or CI/CD pipelines can be used.

Automation It is possible to create a tool that automatically calculates M and shows its changes over time.

Dynamic weights Weights may depend on the domain, system scale, or stage of product development.

Incorporating costs The model can be extended to include the costs of deployments, changes, and failures, which would allow for a better alignment between architecture and business.

Critique of the model

The model also has significant limitations.

Subjectivity: Many values are estimated, which means the result depends on the person performing the evaluation.

Illusion of precision: A single number may give the impression of high accuracy, even though it is a simplification.

Reduction of complexity: System architecture is not only about code and infrastructure. The model does not account for factors such as team organization or processes.

Potential for manipulation: By changing definitions or weights, the result can be influenced. Therefore, consistency in how the metric is calculated is more important than the number itself.

Summary

The Monolith Factor is not a tool for evaluating systems or teams. It is a way to:

1. better understand the architecture
2. have more concrete discussions
3. make informed decisions

What matters most is not whether a system is a monolith or based on microservices, but whether we understand its structure and know which changes will have the greatest impact. Equally important is taking into account the maintenance costs after those changes are introduced.

TLTR;