Overview

At this point in time, the HealthTech company realized that its product growth was starting to be affected by the architecture it was using at the moment. The product used to be a monolith Java app, which worked just fine for early stages. As the functionality grew along with the number of users, updates had to go through a full-cycle deployment process, which led to certain delays.

The company needed to introduce changes that would help in delivering new versions faster, making updates easier, and scaling the project efficiently in the future. Star Systems’ strategy during this transition phase was to find bottlenecks and make the system more flexible and efficient to use.

Business Challenges

This was mainly attributed to the tightly connected monolithic approach that made all parts interdependent and thus every change would lead to re-deployment of the whole application. Testing and deployment processes took a lot of time as well as carried some risks. The 4-hour long process of deploying a change was a real bottleneck especially because of the fast-growing expectations from users who wanted regular updates.

• 4-hour deployment cycles delaying releases
• Risky deployment of whole applications
• Monolithic Java system with tightly connected components

With 12 people working on the same project, developers’ performance was hampered by constant coordination and dependency management.

Alongside technical limitations, the development workflow itself was affected. With 12 developers working on different features, coordination became complex. Since all changes had to be released together, developers often had to wait for deployment windows, which reduced productivity and delayed progress. This created a bottleneck where one delayed feature could hold back the entire release. Poor performance was also becoming a major problem because of an increasing number of users and high traffic the system received. It wasn’t possible to increase efficiency simply by adding more hardware since there were limits of scalability for a monolithic architecture.

Approach

Star Systems, a leading Microservices Migration Company began the decomposition process by holding domain-driven design workshops to determine how the application is structured. It helped define clear service boundaries and align the transformation with the operational needs rather than purely technical considerations. Eventually, the monolith was decomposed into 14 independent microservices performing a certain function.

• Domain-driven design workshops to define service boundaries.
• Decomposition of monolith into 14 microservice.
• Independent services aligned with business functions.

In order to achieve greater consistency and reliable deployment, every service was containerized through Docker to ensure that an application worked properly, no matter whether it was developed, tested, or moved into the production environment. Moreover, Kubernetes was used for container management and enabled scaling and automatic load balancing.

As a next step, Star Systems introduced a GitOps CI/CD pipeline that used ArgoCD. Thanks to it, the developers had the ability to push their changes separately instead of doing so along with the release of the whole system. The process became much faster as it took just minutes instead of hours.