The microservices implementation was the next step in our collaboration with the retail bank that had previously ordered a new debt collection system. In the first phase of building the debt collection management system for the bank, we participated in the redevelopment of the predictive dialing system (PDS) based on the microservices approach. The reward for success was our greater involvement in replacing the legacy architecture.
- The PDS — overhauled
- The brokerage system — in progress
- The anti-money laundering (AML) solution — in progress
As the Bank grew it became obvious to them that monolithic approach proved to be counterproductive for some dynamic banking systems that required frequent changes. That is why the bank decided that implementation of the microservices architecture (MSA) in some cases would be the best practice.
This change came about not because of the trendiness of microservices in finance software, but because of some scalability issues with the system :
- The structure was too complex and posed high risks of performance disruption
- Maintenance and new features development was too resource-intensive and time-consuming
- Learning curve for new people was high, so any substitution was costly.
When redesigning the architecture, it was necessary to take into account new challenges and risks incurred by the MSA. First, the architecture was more complex than the previous patterns used for the same purposes. Second, massive interactions between the microservices opened more possibilities for unauthorized access. Third, the efficiency of the entire system highly depended on how rigorously it was implemented, which placed an even higher responsibility on the development team.
Also, the microservices approach is not a silver bullet and the redevelopment of all the banking systems would be too expensive and not rational decision that is why it was vital to choose what had the most pressing needs to substitute the monolithic architecture.
During the preliminary research of the bank’s high-level architecture and existing systems all the challenges were taken into consideration and the right systems were selected. Additionally, as we were not the only party dealing with this project, our areas of our responsibility were defined:
- The PDS: reassembling the existing backend into microservice containers.
- The brokerage system: conducting system analysis, developing functional and non-functional requirements, and connecting banking applications through microservices.
- The AML system: conducting system analysis; further development is being planned.
The microservices architecture functions on independent lightweight modules, which are grouped around particular features. These microservices in the customer’s banking applications exchange data via a variety of compatible formats and protocols. These protocols are then synchronized on demand.
The Legacy Dialing System Reinvented
The PDS was one of the systems that the client was going to change. But it was an essential part of the debt management system we had been working on, and since we had very strict and mission-critical deadlines, the microservices implementation approach that was initially planned by the client turned out to be impossible — we simply didn’t have enough time for stabilisation.
The RND Point’s team advised the bank against the approach they initially proposed. Instead, after some investigation done under strict pressure we suggested repackaging the legacy system logic into microservices containers, which would allow finishing the debt collection software on time with minimized risks.
So defining the right approach was the most difficult thing here and once this was done in an optimal way we faced no issues during the development process. As the refined dialing system was successfully delivered, our QA engineers ran standard tests to ensure that everything went to plan.
The Brokerage System Analysis and Development
The brokerage service features diverse processes relying on a variety of factors and external data sources. For example, receiving up-to-date stock exchange information depends on regular pass-through queries of a string of third-party services.
The system’s McS NewsArticle module obtains data from the internal trading intelligence database. Further, the database receives data from third-party online services such as QUIK, NSD, and RU Data. On its way to the database, each piece of data gets through a specific converter. To ensure uninterrupted and secure connectivity within these processes, we packaged each of them into individual microservices.
During the development process, we identified some flaws in the previously designed architecture. To correct them, our team added several interim microservices, which improved the workflows and mitigated the defects. We also successfully addressed several change requests during the programming phase.
For example, the QUIK stock trading information access system has a limited amount of sessions available. We developed a hub for gathering requests and sending them in batches. It helped to cover the need for sending the massive amount of requests from the banking system.
A much more challenging part was to set up CI/CD and deploy the infrastructure properly, taking into account the bank’s internal policies and interconnectedness of their systems. For this, our team delved into the bank’s existing rules and gained all the accesses required to set up the data transfer.
At the AML defining stage, we have been working on the functional requirements which our developers will translate into code and configure the CI/CD processes later.
The architectural changes we implemented have opened the way for easy and risk-free implementation of new features. The choice of microservices also proved to be much more cost-effective compared to the legacy architecture.