Microservices, Continuous Architecture, and Technical Debt Interest: An Empirical Study

Continuous Architecture (CA) is an approach that supports companies in decreasing the time between deliveries. Migration to microservices is one of the most common situations when companies adopt continuous architecting processes [4]. Companies commonly adopt an initial migration strategy to extract some components from the monolithic system as microservices, making use of simplified microservices patterns [5][4]. As an example, companies commonly directly connect the microservices to the legacy monolithic system and do not adopt any message bus at the beginning. When the system starts to grow in complexity, they usually start re-architecting their systems, considering different architectural patterns. Some companies introduce API gateway patterns to simplify the management and load balancing of the different services, while others also consider a lightweight message bus [4][5][6]. All these architectural changes require deep refactoring of the system, thereby increasing the risk of new faults being introduced. In this paper, we report the preliminary results of work in progress, where we monitored the TD of an SME (SMEs = small and medium enterprises) that adopted a CA approach while migrating a legacy monolithic system to an ecosystem of microservices. To the best of our knowledge, no studies exist on the impact of postponed activities on the TD, especially in the context of CA and microservices. This work will help companies understand how TD grows and changes over time while at the same time opening up new avenues for future research on the analysis of TD interest in continuous architecting processes.

💡 Research Summary

This paper investigates how technical debt (TD) and its “interest” evolve when a legacy monolithic system is migrated to a microservices architecture under a Continuous Architecture (CA) approach. CA promotes postponing design decisions until they become absolutely necessary, a practice that can accelerate feature delivery but may also defer essential refactoring, thereby accumulating debt. The authors conduct an empirical case study on a Finnish small‑medium enterprise that maintained a 280 K‑line Java document‑management system for more than twelve years before beginning a staged migration in March 2017. The migration extracted four business processes into independent microservices; two of these services later underwent substantial re‑architecting (MySQL → MongoDB and a rewrite from Java to Python) to exploit new capabilities.

Data were collected from the company’s GitLab repository and Jira issue tracker over a four‑year window: two years before migration (2015‑2016) and the migration period (2017‑2018). Each commit was analyzed with SonarQube, which provides a TD estimate expressed in person‑hours based on a standard quality profile. The authors plotted TD trends for the whole system (monolith + microservices) and for each microservice individually.

Key findings are: (1) the monolithic system’s cumulative TD before migration was roughly 2,000 hours; after migration the total TD (including the remaining monolith and the new services) more than doubled, exceeding 4,000 hours. (2) At the service level, TD spikes shortly after a service is created but then declines within three to four months, reflecting rapid refactoring and optimization once the service is in production. (3) The overall TD growth rate after migration is significantly higher than the pre‑migration trend, which the authors attribute to a large number of “postponed” refactoring activities that accrue interest over time.

The discussion emphasizes that while microservices can isolate debt and enable faster local remediation, the system‑wide debt can still balloon if many refactoring tasks are delayed under the CA philosophy. The authors acknowledge several threats to validity: the study is based on a single organization, SonarQube’s metric may not capture all dimensions of debt, and hidden complexities such as API‑gateway or message‑bus interactions are not reflected in the analysis.

Future work aims to quantify technical‑debt interest more precisely by tracking the actual effort spent on each postponed issue versus the effort that would have been required had the issue been addressed immediately. This will involve mixed‑methods research combining developer interviews with mining of software repositories, following the approach of previous work on OSS trustworthiness. The ultimate goal is to provide decision‑support guidance for when to defer versus when to perform refactoring in a CA‑driven microservices migration.

In conclusion, the study confirms that Continuous Architecture’s “delay‑until‑necessary” stance can lead to a rapid increase in total technical debt during a microservices migration, even though individual services tend to stabilize and reduce debt after an initial adjustment period. Practitioners are therefore advised to monitor debt at both the system and service levels and to balance the short‑term benefits of postponed design decisions against the long‑term cost of accumulated debt interest.