Load balancing BridgeGate Workbench
Updated on October 21, 2025
•
Published on October 21, 2025
Benefits of load balancing BridgeGate Workbench
Load balancing the BridgeGate integration platform (which includes Workbench and its resulting integration processes) are High Availability, enhanced performance, and scalability:
- High Availability (HA): Load balancing ensures continuous operation by automatically detecting if a BridgeGate server fails or is taken down for maintenance. It immediately reroutes traffic and processing to other healthy servers in the cluster, eliminating a single point of failure and preventing downtime for critical data integrations.
- Enhanced performance: It improves throughput and reduces latency by evenly distributing incoming data integration workloads across multiple BridgeGate server instances. This prevents any single server from becoming overloaded, ensuring faster processing and response times for data transformations and workflow executions.
- Scalability: Load balancing makes it easy to scale horizontally by adding or removing server instances as data volume fluctuates (e.g., during peak processing hours). This allows the BridgeGate environment to handle massive spikes in transaction volumes without manual intervention and optimizes resource utilization and cost.
About BridgeGate Workbench
BridgeGate Workbench is the Graphical User Interface (GUI) component of the BridgeGate integration platform, which is designed to enable secure communication and interoperability between disparate platforms, applications, and DICOM workflows.
Why Loadbalancer.org for BridgeGate Workbench?
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 BridgeGate Workbench
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 BridgeGate Workbench, Layer 7 Reverse Proxy is recommended.
Virtual service (VIP) requirements
To provide load balancing and HA for BridgeGate Workbench, the following VIPs are required:
| Ref. | VIP Name | Mode | Port(s) | Persistence Mode | Health Check |
|---|---|---|---|---|---|
| VIP 1 | BridgeGateWorkbench | L7 Reverse Proxy | 80 | HTTP Cookie | Connect to Port |
Load balancing deployment concept
Once the load balancer is deployed, clients connect to the Virtual Service (VIP) rather than connecting directly to one of the BridgeGate Workbench servers. These connections are then load balanced across the BridgeGate Workbench servers to distribute the load according to the load balancing algorithm selected.
Note
The load balancer can be deployed as a single unit, although Loadbalancer.org recommends a clustered pair for resilience and high availability.
Load balancing topology
Layer 7 Reverse Proxy can be deployed using either a one-arm or two-arm configuration. For two-arm deployments, eth1 is typically used for client side connections and eth0 is used for Real Server connections, although this is not mandatory since any interface can be used for any purpose.
For more on one and two-arm topology see Topologies & Load Balancing Methods.
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 either 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.
The image below shows an example Layer 7 Reverse Proxy network diagram:
Because Layer 7 Reverse Proxy is a full proxy, Real Servers in the cluster can be on any accessible network 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 2 ways. Either by inserting a header that contains the client’s source IP address, or 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. For more information on these methods, please refer to Transparency at Layer 7 in the Enterprise Admin Manual.