Benefits of load balancing Fiserv DNA SAF Server

Load balancing Fiserv’s DNA SAF Service and Application Framework (SAF) Servers provides High Availability, scalability and optimized performance:

• High Availability (HA): Load balancing is essential for ensuring the system remains operational even if a server fails. By directing traffic to a pool of two or more SAF servers, the load balancer eliminates the single point of failure that a single server presents. If a load balancer detects that a specific SAF server is unhealthy (via continuous health checks) or has failed, it automatically and seamlessly reroutes all incoming requests to the remaining operational servers. This minimizes downtime and ensures uninterrupted service delivery for critical financial transactions.
• Scalability: Load balancing allows the system to easily handle growth in user load and transaction volume. As your financial institution grows and more users or services interact with DNA, traffic spikes can overwhelm a single server. Load balancing allows you to add additional SAF servers to the pool, immediately increasing the capacity of the system to manage the growing workload. This design provides a flexible architecture that can be scaled up or down quickly in response to fluctuating business needs without a major architectural overhaul.
• Optimized performance: Load balancing ensures that all available resources are utilized efficiently, leading to faster response times. The load balancer uses intelligent algorithms (like Least Connections or Round Robin) to ensure that traffic is distributed evenly, preventing any single SAF server from becoming a bottleneck due to overload. By directing requests to the most available or least-busy server, load balancing helps reduce server response times and overall latency, ensuring a faster and smoother user experience for tellers and end-users.

About Fiserv DNA SAF Server

Fiserv DNA SAF (Service and Application Framework) servers are a critical component of the Fiserv DNA core banking system, providing the enterprise service bus (ESB) and foundational middleware necessary for the platform’s distributed and modern architecture. These servers host the application logic, business services, and APIs that allow various components of the DNA ecosystem—including the user interface, third-party integrations, and other internal services—to communicate and exchange data securely and efficiently. By centralizing core functionality and providing a highly scalable and resilient layer, the SAF servers ensure that all transactions and service requests are processed reliably, making them essential for maintaining the performance and high availability required for mission-critical operations in financial institutions.

Why Loadbalancer.org for DNA SAF Server?

Loadbalancer’s intuitive Enterprise Application Delivery Controller (ADC) is also 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 Fiserv DNA Connect Server

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 Fiserv DNA Connect Server, Layer 7 Reverse Proxy is recommended.

Virtual service (VIP) requirements

To provide load balancing and HA for Fiserv DNA SAF Server, only a single VIP is required:

• SAF

Load balancing deployment concept

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