The microservices architecture (MSA) implementation was the next step in our collaboration with the retail bank that had previously ordered a New Debt Collection Software. 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.
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 microservicesarchitecture (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 :
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 a 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, the areas of our responsibility were defined:
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.
By implementing Magento Commerce 2, the client now has a fully-featured, stable, scalable, and extendable platform that will support future business growth. The extended capabilities allow the client to keep customers informed throughout the purchasing process of banking products.
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 stabilization.
Our 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 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.
Integration with third-party services enabled to call the Magento web APIs. The Magento APIs currently support Accounting, Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Product Information Management (PIM), and marketing automation systems for the client.
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 legacy architecture.
