# General Overview

Source: https://docs.interop.io/bridge/general-overview/index.html

## What Is io.Bridge?

**io.Bridge** is a distributed server-side app that provides connectivity between the io.Connect platforms ([**io.Connect Desktop**](https://docs.interop.io/desktop/getting-started/what-is-io-connect-desktop/general-overview/index.md) and [**io.Connect Browser**](https://docs.interop.io/browser/getting-started/what-is-io-connect-browser/index.md)), your [interop-enabled apps](https://docs.interop.io/desktop/getting-started/how-to/interop-enable-your-apps/overview/index.md) running on different machines, and third-party apps for which you are using [Application Adapters](https://docs.interop.io/adapters/general-overview/index.md) (Microsoft Office apps, Bloomberg, Fidessa, Salesforce, and more).

**io.Bridge** comes with a configurable embedded io.Connect Gateway which can be used as an alternative deployment option to the embedded io.Connect Gateway that is distributed by default with the io.Connect platforms.

The **io.Bridge** service can be hosted in a third-party cloud environment (e.g., AWS), in a local cloud (on-premise deployment), and can also be run locally on the user machine.

The cloud-based deployment of **io.Bridge** is intended for simultaneous multi-user support - i.e., multiple users utilizing a shared instance of **io.Bridge**. Contextual data isn't shared between the users.

**io.Bridge** is horizontally scalable in order to be able to handle varying load amounts. This enables **io.Bridge** to support high-availability deployments. The io.Connect Gateway connections and data traffic are load-balanced in-memory across the **io.Bridge** cluster. The cluster is composed of multiple **io.Bridge** node instances. Each node is responsible for managing the connections between the io.Connect Gateways and synchronizing with all other **io.Bridge** nodes. The cluster can be scaled dynamically based on the load. When new nodes are added to the cluster, the load balancer automatically starts to distribute the load across the new nodes.

## Why Use io.Bridge?

**io.Bridge** is an interoperability solution that can be applied in cases where certain technological or infrastructural limitations exist.

While the **io.Connect Desktop** platform supports interoperability between web, native, and third-party apps, the web-based **io.Connect Browser** platform can't by itself provide interoperability support for native apps or third-party that don't have web APIs. You can use the **io.Bridge** capabilities to surpass this limitation and connect your **io.Connect Browser** project with your interop-enabled native apps and other third-party apps.

It's not uncommon for enterprise users to have setups on multiple machines. For instance, a trader may be using in-house interop-enabled web and native apps powered by the **io.Connect Desktop** platform on one machine and one or more third-party trading apps like Bloomberg or Fidessa powered by the respective io.Connect [Application Adapter](https://docs.interop.io/adapters/general-overview/index.md) on another machine. In this case, you can [deploy](https://docs.interop.io/bridge/deployment/overview/index.md) **io.Bridge** to establish an interoperability connection between the io.Connect platform on one machine and the io.Connect Application Adapters on the other.

**io.Bridge** can also be deployed in the cloud to enable secure and scalable cross-machine interoperability without having to install additional software on the machines of your users. This setup can be used to provide a zero-install experience for **io.Connect Browser** users if you want to enable interoperability between **io.Connect Browser**, interop-enabled native apps, and third-party apps powered by the io.Connect Application Adapters.

## Architecture

**io.Bridge** consists of the following components:

- **Gateway Broker** - a broker that manages the connections between the io.Connect Gateways;
- **Remote Gateway** - an io.Connect Gateway that provides connectivity between **io.Connect Browser**, interop-enabled native apps, and third-party apps powered by the io.Connect Application Adapters;
- **Bridge Broker** -  a broker that manages the connection and the synchronization between the members (**io.Bridge** node instances) of the **io.Bridge** cluster;

![](https://docs.interop.io/bridge/images/bridge-architecture.png)

## Performance Testing

The performance tests validate that **io.Bridge** satisfies real-world customer workloads by simulating multi-platform, multi-device user interactions. The tests use [Grafana K6](https://k6.io/) as a performance testing framework. Each user connects from two devices simultaneously (a persistent main workstation, referred to as a Stable User (SU), and a short-lived session from a temporary device, referred to as a Dynamic User (DU)) triggering the message flow via **io.Bridge**. Messages have varying lengths and randomized inter-message delays. The **io.Bridge** container starts with 422 MiB of memory and 0.025 virtual CPU (vCPU), with a maximum allocation of 2.4 GiB. The test configuration uses a custom Average Generator (AG), specified as `AG(min, average, max)`, for randomized parameters, and a Message Generator (MG), specified as `MG(min, average, max)`, for producing messages with varying lengths.

The following sections describe the results from executing two test scenarios with 500 and 800 Virtual Users (VU) respectively.

### 500 VU

#### Configuration

| Configuration Property | Value |
|------------------------|-------|
| Stages | `29m:509,80m:509,10m:509,1m:0` |
| Percent SU | 40 |
| SU Channels | `AG(3, 5, 10)` |
| SU waiting time between messages | `AG(60, 150, 300)` |
| DU messages per session | `AG(3, 7, 10)` |
| DU waiting time between messages | `AG(30, 120, 180)` |
| Additional characters in messages | `MG(500, 1500, 15000)` |

#### Results

**io.Bridge** resource usage remained stable during the test and returned to pre-test levels after completion:

![io.Bridge Resource Usage - 500 VU](https://docs.interop.io/bridge/images/performance-testing-500VU-bridge-metrics.png)

| Resource | Before | Starting Up | During | Teardown | After |
|----------|--------|-------------|--------|----------|-------|
| vCPU | < 0.005 | max 0.119 | 0.119 - 0.147 | down to 0.017 | < 0.005 |
| Memory | 183 MiB | 359 MiB | 370 MiB | to 176 MiB | 178 MiB |

The test container CPU and memory usage were well within the allocated limits of 4 vCPU and 12 GiB:

![Test Container Resource Usage - 500 VU](https://docs.interop.io/bridge/images/performance-testing-500VU-test-container.png)

Message performance metrics:

| Metric | Min | Median | Average | p(95) | p(99) | Max | Count |
|--------|-----|--------|---------|-------|-------|-----|-------|
| Messages from DU to DU duration | 9 ms | 12 ms | 12.97 ms | 20 ms | 30 ms | 261 ms | 10 355 |
| Messages from DU to SU duration | 11 ms | 16 ms | 25.98 ms | 65 ms | 111 ms | 9 715 ms | 3 493 |
| Messages from SU to DU duration | 10 ms | 14 ms | 27.82 ms | 76 ms | 131 ms | 390 ms | 3 485 |
| Messages sent by DU length | 500 | 740 | 1 494.19 | 5 025 | 8 015 | 12 588 | 10 717 |
| Messages sent by SU length | 500 | 748 | 1 503.40 | 5 092 | 8 187 | 13 172 | 8 518 |
| WebSocket connecting | 6 ms | 11 ms | 12.62 ms | 18 ms | 36 ms | 247 ms | 16 110 |
| WebSocket session duration | 9 ms | 17 ms | 355 616 ms | 1 283 086 ms | 5 991 511 ms | 7 023 300 ms | 16 108 |

### 800 VU

#### Configuration

| Configuration Property | Value |
|------------------------|-------|
| Stages | `29m:809,80m:809,10m:809,1m:0` |
| Percent SU | 40 |
| SU Channels | `AG(3, 5, 10)` |
| SU waiting time between messages | `AG(60, 150, 300)` |
| DU messages per session | `AG(3, 7, 10)` |
| DU waiting time between messages | `AG(30, 120, 180)` |
| Additional characters in messages | `MG(500, 1500, 15000)` |

#### Results

**io.Bridge** resource usage remained stable during the test and returned to pre-test levels after completion:

![io.Bridge Resource Usage - 800 VU](https://docs.interop.io/bridge/images/performance-testing-800VU-bridge-metrics.png)

| Resource | Before | Starting Up | During | Teardown | After |
|----------|--------|-------------|--------|----------|-------|
| vCPU | < 0.005 | max 0.121 | 0.121 - 0.191 | down to 0.017 | < 0.005 |
| Memory | 179 MiB | 414 MiB | 426 MiB | to 173 MiB | 179 MiB |

The test container CPU and memory usage were within limits, except for a brief 6-minute period where memory reached 10.9 GiB, slightly exceeding the 90% threshold (10.8 GiB) of the allocated 12 GiB:

![Test Container Resource Usage - 800 VU](https://docs.interop.io/bridge/images/performance-testing-800VU-test-container.png)

Message performance metrics:

| Metric | Min | Median | Average | p(95) | p(99) | Max | Count |
|--------|-----|--------|---------|-------|-------|-----|-------|
| Messages from DU to DU duration | 9 ms | 12 ms | 13.5 ms | 22 ms | 43 ms | 211 ms | 16 701 |
| Messages from DU to SU duration | 10 ms | 16 ms | 23.79 ms | 68 ms | 111 ms | 749 ms | 6 095 |
| Messages from SU to DU duration | 9 ms | 14 ms | 28.64 ms | 79 ms | 127 ms | 319 ms | 5 599 |
| Messages sent by DU length | 500 | 744 | 1 502.38 | 5 139 | 8 038 | 12 644 | 17 045 |
| Messages sent by SU length | 500 | 748 | 1 516.21 | 5 136 | 8 269 | 13 000 | 13 479 |
| WebSocket connecting | 6 ms | 11 ms | 12.41 ms | 17 ms | 41 ms | 1 069 ms | 25 467 |
| WebSocket session duration | 9 ms | 17 ms | 357 778 ms | 1 284 117 ms | 6 158 442 ms | 7 001 346 ms | 25 466 |