Homepage > Portfolio > Banking Software Design for Financial Corporation

Banking Software Design for Financial Corporation

The Azati team designed new architecture for the financial institute to reduce the load on the back-end system and optimize the processing of users’ requests.


Today many companies are turning to online services to facilitate the work with the most frequently used processes. Automation increases the number of services that could be provided without attending the human operator. The banking industry is no exception.

Probably, most of us have been using online banking for a long time already, where almost any transactions and banking operations occur through the use of mobile or web applications: whether paying for the bills or transferring funds to another bank account.

Our customer is a large CIS commercial institute, which turned to Azati to optimize a very specific banking service, as it did not meet the requirements of speed, stability and overall efficiency.


End-users complained that the performance of the mobile application for online banking left much to be desired – it took about 15 seconds to load on a typical device. After initial analysis, the Customer found out that the service responsible for obtaining transaction histories heavily loaded the application.

When our team joined the project, the service which collected transaction history was already developed, fully functional, and actively used.

Due to the fact that the software had a monolithic architecture – any operation failure of one service affected the operation of all the others.

The main goal of Azati was to split a huge service into small blocks – microservices, and design a new architecture. Each microservice should work “separately” in a dedicated environment, and in case of an error in one of them, the problem is localized and does not drag down a chain of errors.




The Customer wanted Azati to create a cloud-based microservice architecture. The first challenge engineers faced was to decide what infrastructure to use: a third-party cloud provider like Amazon or a self-managed cloud.

Some questions arose regarding safety, legislation and time it can take to develop their own product. As a result, the team decided to create an independent architecture.



To solve the problem with a high resource load, engineers proposed a solution that included the architecture redesign, dividing each functional unit into microservices.

However, the transition to the new architecture is always a dreary and time-consuming process. The customer was not ready to make changes to the existing architecture quickly, as this requires a large number of approvals at different levels and bank lines.




Yet another noticeable factor was that the SQL requests were not optimized. Instead of one complex query, the existing service sent several small ones. And after receiving the result, data required additional time and resource-consuming post-processing.

Such an approach slowed the data bus since it must, address a considerable number of small requests to other services and await the results.


First of all, it should be noted that our team was working with the customer under other projects and tasks, so we were already familiar with the software architecture and documentation.

The team looked through the documentation, analyzed project specification and performance requirements. Engineers also analyzed server responses, the way a service collects data before sending it to the frontend, as well as general performance metrics. The main goal of the team at this stage was to find out where the bottleneck is – whether it is a backend itself, or it is a data exchange bus.

After initial analysis, the team discovered that even the data bus could work faster, the main bottleneck of a system is a substantial monolithic service – which acts both as a gateway and as a processing center.

Engineers proposed to split this service into a group of small services – microservices. The most significant advantage of microservices is that it is possible to launch several instances of a single service on different machines and parallel the load to the newly added instances. It means that if a gateway service experiences a huge load it does not take the resources which are required for other services to work fast – as they run on different machines.

Engineers created a breakout of a single service to a group of microservices. Have a look at the UML diagram.

To prove the efficiency of the new architecture, the team created an MVP and conducted stress testing to find out that after the redesign the performance snag was related to the data exchange bus.

Yet another recommendation to accelerate the load of a mobile app was to remove the widget responsible for the operation history from the main page. It subsequently increases a number of requests and makes it difficult to load the page on the whole and in most cases the user does not need it from the very beginning.


Azati redesigned the existing service – split it into several separate interconnected microservices. The team prepared documentation and recommendations for further actions, including the transfer of microservice data to Spring Cloud.

Let’s have a look at microservices our engineers decided to implement

  • Frontend Apps
    A group of applications that is fully responsible for the generation of user interface and working with custom widgets.
  • Auth Service
    Auth Service functions as an additional layer for user identification and authorization. It is a gateway built with proprietary technologies but still can be moved to the cloud.
  • Config Service
    Config Service provides support for both client and server sides to enable external configuration in a distributed system. During the whole deployment pipeline from testing to production you can manage configuration the environments need to run.
  • API Gateway
    API Gateway works as an entry point of the system. First of all, all requests go through the service and then, the gateway redirects them to the corresponding microservices.
  • Service Discovery Server
    This microservice is responsible for statistics collection: how many and which instances are currently running. It is a standard component of cloud architecture.
  • Operation History
    This service is responsible for displaying the complete history of user operations.
  • DB Connector
    The service allows other microservices to connect to the database in order to provide access to the internal banking data.
  • Data Bus Connector
    Data Bus Connector – this microservice is designed to “communicate” with a banking bus.
  • Data Bus
    Data Bus – hardware or software subsystem that provides data transfer within the system – WSO2.

The Customer also followed our recommendations and moved the operations history to a separate screen. Such a move increased the overall performance and greatly improved the application load speed.




  • Engineers prepared detailed analysis of the existing solution
  • Azati designed new microservice architecture for one of the most loaded services
  • Engineers built an MVP, stress-tested it, and presented to the Customer
  • The team prepared all the documentation required for further development

Unfortunately, due to the coronavirus pandemic the Customer decided to postpone the development, but Azati hopes to finalize the MVP as soon as the situation stabilizes.

Drop us a line

If you are interested in the development of a custom solution — send us the message and we'll schedule a talk about it.