On top of the brief list of case studies shared earlier, we thought it would be only logical to share some deeper internal details of a project, so you would be able to make better assessment of the CodeXteam's capabilities.

One of our healthcare customers came to us with a problem that drastically affected their application performance during evening hours – the time when as much as 60% of their end-users were active in the system. The users complained about the overall application slowdown that happened between 5 pm and 6 pm and varied in its duration from several minutes to more than half an hour. The problem did not reoccur every day and appeared to be random.

We at CodeXteam were granted permission to the application's monitoring performed by NewRelic One and conducted a thorough analysis of the possible root causes for the slowdown. At the first glance, we noticed two probable anomalies in the usage patterns of the system resources:

• first, to the contrary of the usual workload, the database was busy for longer and the application experienced delays in serving the user requests because it was waiting for a database connection to become available from the pool;
• second, when the application finally had received the data from the database, it spent tens of seconds performing a series of network-bound operations.

Following further investigation that involved interviewing the customer's development team leader along with the members of the business unit, we revealed that the performance downgrade might have been caused by the reporting tool that ran on schedule gathering some business-related data, and sending out the reports via email. The customer's development team agreed to this conclusion, so the next step for us was to suggest a solution that would enable the application to run without further freezes and at the same time, keep the reporting tool doing its job on time.

The solution CodeXteam offered comprised three major transformative steps:

• introducing a read replica of the production database;
• extracting the reporting part of the main application into a standalone service;
• extracting the mail sending logic into a standalone service that would get data to be sent asynchronously.

Luckily, the customer has their database hosted on AWS RDS, so introducing the read replica did not cause any downtime and was performed seamlessly.

The next step involved CodeXteam's engineering team analyzing and refactoring the existing codebase in close cooperation with the customer's development team. This joint effort resulted in the timely and efficient delivery of a reporting microservice built on top of the Spring Boot framework, that largely reused the existing reporting framework source code, yet became decoupled from the main application.

The last step took even less time and did not require the customer to increase the number of EC2 instances needed to run the application. Introducing short-living AWS Lambda functions that had an AWS SQS message for a trigger proved to be a resource- and cost-efficient solution for sending out the emails containing important reports.

As a result, neither the customer's monitoring team nor the end-users reported any further performance issues over the month following the transformation performed by the CodeXteam. At the same time, the overall application architecture became less coupled, more transparent, and easier to support.