Migration from a monolith to a modular monolith or microservices: criteria for decomposition and antipatterns

Abstract

The article examines the multicriteria problem of migrating long-lived software systems from monolithic architecture to a modular monolith and microservices, with an emphasis on correct “slicing” along domain boundaries and the prevention of typical antipatterns, primarily the distributed monolith. It is shown that architectural decomposition is not an end in itself and, when transactional boundaries, dependency graphs, and load profiles are ignored, leads to increased network latency, more difficult diagnostics, and higher total cost of ownership. Based on material from 124 projects with long-term operation and a large cumulative codebase, static metrics of module coupling and stability are compared with operational indicators (latency, MTTR, deployment frequency, release incident rate) and organizational effects, including the reallocation of effort toward DevOps and contract alignment. Quantitative results reveal a nonlinear trade-off: microservices reduce local complexity and accelerate the release cycle, but can nearly double response time and significantly increase infrastructure costs, while simultaneously increasing teams’ cognitive load; the modular monolith demonstrates a more balanced profile, providing a noticeable reduction in coupling with minimal performance degradation. The material enables an assessment of the relevance of architectural strategy choices depending on availability requirements, team scale, and the maturity of observability and platform engineering practices.