From Monolith to Microservices: Talgat Akunsartov Shares Experience of Architectural Transformation in Java Projects

Abstract: This article focuses on the analysis of the architectural transformation process of software systems from a monolithic to a microservice architecture in the context of Java development. The aim of the study is to systematize the theoretical foundations and practical experience of this transition, as well as to identify the main advantages and challenges accompanying it. The research objectives include examining the theoretical prerequisites for the emergence of microservices, analyzing the methods for decomposing monolithic systems, and describing the tools used in the Java ecosystem for implementing microservice architectures. The paper presents a generalized case study illustrating the sequence of migration stages. The results of the research provide comprehensive recommendations for development engineers and software architects planning or carrying out similar transformations. The practical significance of this article lies in offering structured guidance for making informed decisions when selecting and implementing microservice architectures in real-world projects.

Keywords: microservice architecture, monolith, Java, Spring Boot, decomposition, refactoring, domain-driven design, containerization, cloud computing, architectural transformation.

In the context of modern information technology development and the continuously increasing business requirements for scalability, flexibility, and deployment speed, architectural patterns are undergoing significant transformation. The traditional monolithic architecture, which has long dominated the development of enterprise systems in Java, faces a number of limitations, including maintenance complexity, constrained scalability, and slow delivery of new features.

In response to these challenges, microservice architecture has gained widespread adoption. This approach promotes the decomposition of a system into a set of loosely coupled, independently deployable services. The relevance of this topic is determined by the growing need for effective strategies to transition from monolithic systems to microservices, as well as the necessity to systematize the experience and tools available to Java developers for carrying out such transformations.

The goal of this article is to analyze and summarize the experience of architectural transformation in Java projects, providing both theoretical justification and practical recommendations for a successful transition from monolith to microservice architecture.

Monolith vs. Microservices

A monolithic architecture is characterized by the fact that all functional components of an application are combined into a single deployable module [2]. This simplifies development in the early stages but leads to several problems as the system grows in complexity: difficult scalability (the entire system must be scaled even if only one module requires it), long startup times, challenges in adopting new technologies, and slow delivery of new features due to a large codebase and high interdependence between components.

In contrast, a microservice architecture represents an approach to developing a single application as a collection of small services, each running in its own process and communicating through lightweight mechanisms, often HTTP-based APIs [1]. Each service can be developed, deployed, and scaled independently. This ensures greater fault tolerance, flexibility in choosing technologies, and shorter time-to-market for new features.

Основные различия между архитектурами представлены в Таблице 1.

Methods of Monolith Decomposition and Practical Implementation

The transition from a monolithic to a microservice architecture is a complex, iterative process often compared to "cutting the cheese" or the "dirty knife strategy" [2]. Several approaches are used for monolith decomposition:

• By Domain Areas (DDD): Independent business domains (for example, "Product Management" or "Users") are separated into individual microservices.
• By Functionality: Cross-cutting functions, such as authorization or payments, are extracted into standalone services.
• Strangler Fig Strategy: Components of the monolith are gradually and safely replaced with new microservices until the legacy system is completely phased out [3].

The practical implementation of these approaches in Java projects typically includes the following steps:

1. Database Separation: Extracting the data related to a specific service into its own dedicated database.
2. API Gateway Creation: Implementing a single entry point for all microservices, which handles request routing and may perform authentication and authorization functions.
3. Use of Lightweight Frameworks: In Java development, Spring Boot is widely adopted as it significantly simplifies the creation of standalone, production-ready microservices thanks to its minimal configuration and built-in web server.

Example: Transformation of an Order Management System

Let us consider a hypothetical case of transforming a monolithic Order Management System developed on Java EE.
The original system was a single WAR application that included modules for product management, users, cart, and order processing, all sharing one relational database.

Stages of Transformation:

1. Domain Analysis: The following domains were identified—Products, Users, Cart, and Orders.
2. Extraction of the "Products" Service: The first service to be extracted was "Products," as it had relatively low coupling with other modules. A new Spring Boot microservice was created with its own database (for example, MongoDB for the product catalog) and a REST API for product management. Monolithic components that previously interacted with the "Products" module were modified to call the new microservice via its API.
3. Extraction of the "Users" Service: Similarly, a separate authentication and user management service was created. This microservice handles registration, authorization, and profile storage, integrating with security systems such as OAuth2.
4. Separation of "Orders" and "Cart": These two domains, being more tightly coupled, were separated at the next stage. The "Cart" service stores temporary data about selected products, while the "Orders" service manages the order lifecycle after checkout, interacting with the "Products" and "Users" services as well as with external payment systems.
5. Implementation of API Gateway: An API Gateway (for example, based on Spring Cloud Gateway) was introduced at the system's front end to centralize client requests and route them to the corresponding microservices.
6. Containerization and Orchestration: Each microservice was packaged into a Docker container. An orchestration platform such as Kubernetes was used to manage and scale containers, ensuring automated deployment, load balancing, and fault tolerance.

Conclusion

Thus, the transition to microservices in Java represents an evolution driven by the need for flexibility, scalability, and system resilience.

This transformation is based on the principles of decomposition and is implemented through technologies such as Spring Boot, Docker, and Kubernetes. Although gradual migration strategies help reduce risks, the transition significantly increases the complexity of managing a distributed system. Achieving success requires deep technical expertise and careful strategic planning.

References

1. Newman, S. Building Microservices: Designing Fine-Grained Systems. Sebastopol, CA: O'Reilly Media, 2015. 278 p.
2. Fowler, M. Monolith to Microservices: A Journey to Microservices [Electronic resource]. Martin Fowler's Website, 2014. Available at: https://martinfowler.com/articles/microservices.html
3. Fowler, M. Strangler Fig Application [Electronic resource]. Martin Fowler's Website, 2024. Available at: https://martinfowler.com/bliki/StranglerFigApplication.html