Benefits of load balancing Finacle Core Banking

Load balancing distributes the massive transaction volume and channel requests (mobile, ATM, branch) across multiple Finacle application servers, ensuring robustness and efficiency:

• Maximum High Availability (HA) and resilience: In core banking, downtime is catastrophic. Load balancing is the key to achieving near-zero downtime. The load balancer continuously monitors the health of all Finacle server components (e.g., application servers, web servers). If a server fails, the load balancer instantly stops sending new traffic to the unhealthy server and redirects all requests to the remaining active and healthy servers. Banks can take individual application nodes offline for patching, upgrades, or configuration changes without interrupting service to customers, ensuring truly 24×7 real-time banking.
• Scalability and peak load handling: Finacle processes billions of transactions and supports massive customer bases. Load balancing provides the foundation for horizontal scaling to handle growth and extreme spikes in demand. It effectively spreads high-volume transactional workloads—like end-of-day processes, real-time payments, and digital banking traffic—across the entire server cluster, preventing any single instance from becoming a performance bottleneck. As the bank grows (e.g., increased customer base, new digital channels, or mergers), new Finacle servers can be added on-the-fly and immediately included in the load balancer pool, allowing the system’s capacity to scale elastically with business demand.
• Consistent performance and optimized throughput: By intelligently distributing the load, the banking system can process transactions faster and more reliably, directly impacting the customer experience. Load balancing algorithms (like “least connections” or “fastest response time”) ensure requests are routed to the server that can respond the quickest, dramatically reducing transaction latency and improving the responsiveness of all banking channels. It prevents the server pool from being under-utilized or over-utilized. By evenly distributing the workload, all available computing resources are used efficiently, maximizing the total throughput (number of transactions processed per second) of the Finacle system.

About Finacle Core Banking

Finacle Core Banking is a comprehensive suite of solutions that meets the deposit, lending, leasing, payments, supply chain, trade finance and Islamic banking requirements of banks worldwide, enabling them to deliver personalized solutions to their customers.

Why Loadbalancer.org for Finacle Core Banking?

Loadbalancer’s intuitive Enterprise Application Delivery Controller (ADC) is designed to save time and money with a clever, not complex, WebUI. 

Easily configure, deploy, manage, and maintain our Enterprise load balancer, reducing complexity and the risk of human error. For a difference you can see in just minutes.

And with WAF and GSLB included straight out-of-the-box, there’s no hidden costs, so the prices you see on our website are fully transparent. 

More on what’s possible with Loadbalancer.org.

How to load balance Finacle Core Banking

The load balancer can be deployed in 4 fundamental ways: Layer 4 DR mode, Layer 4 NAT mode, Layer 4 SNAT mode, and Layer 7 Reverse Proxy (Layer 7 SNAT mode).

For Finacle Core Banking, a Layer 7 Reverse Proxy deployment is recommended. 

About Layer 7 Reverse Proxy load balancing

Layer 7 Reverse Proxy uses a proxy (HAProxy) at the application layer. Inbound requests are terminated on the load balancer and HAProxy generates a new corresponding request to the chosen Real Server. As a result, Layer 7 is typically not as fast as the Layer 4 methods. 

Layer 7 is typically chosen when enhanced options such as SSL termination, cookie based persistence, URL rewriting, header insertion/deletion etc. are required, or when the network topology prohibits the use of the Layer 4 methods.

Because Layer 7 Reverse Proxy is a full proxy, any server in the cluster can be on any accessible subnet, including across the Internet or WAN. 

Layer 7 Reverse Proxy is not transparent by default i.e. the Real Servers will not see the source IP address of the client, they will see the load balancer’s own IP address by default, or any other local appliance IP address if preferred (e.g. the VIP address). This can be configured per Layer 7 VIP. 

If required, the load balancer can be configured to provide the actual client IP address to the Real Servers in two ways:

1. Either by inserting a header that contains the client’s source IP address, or 
2. By modifying the Source Address field of the IP packets and replacing the IP address of the load balancer with the IP address of the client.

Layer 7 Reverse Proxy mode can be deployed using either a one-arm or two-arm configuration. For two-arm deployments, eth0 is normally used for the internal network and eth1 is used for the external network, although this is not mandatory. 

No mode-specific configuration changes to the load balanced Real Servers are required. 

Port translation is possible with Layer 7 Reverse Proxy e.g. VIP:80 → RIP:8080 is supported. You should not use the same RIP:PORT combination for Layer 7 Reverse Proxy VIPs and Layer 4 SNAT mode VIPs because the required firewall rules conflict.

Related Resources