Try it now
CASE STUDY

Microservices Implementation in the Bank: the Architecture that Proves Its Value

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.

  • the predictive dialing system — overhauled
  • the brokerage system — launched
  • the anti-money laundering (AML) solution — launched
9AM - 6PM

Monday – Friday

Get in touch

The Challenge

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 :

  • The structure was too complex and posed high risks of performance disruption
  • Maintenance and new features development was too resource-intensive and time-consuming
  • The 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 a rational decision that is why it was vital to choose what had the most pressing needs to substitute the monolithic architecture.

The Solution

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 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 improvements are planned
  • Magento eCommerce platform integration

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 Result

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 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 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.

Anti-money laundering

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.

eCommerce integration

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 Impact

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.


Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Youtube
Consent to display content from Youtube
Vimeo
Consent to display content from Vimeo
Google Maps
Consent to display content from Google
Spotify
Consent to display content from Spotify
Sound Cloud
Consent to display content from Sound
Get in touch