Use Gateways to connect to Aeron Cluster¶
To achieve optimal results, it is advisable for Aeron Cluster clients to connect through Gateways. For example, consider a scenario where we have an assortment of FIX, UI clients, and a database that needs to interact with Aeron Cluster. In this case, the recommended architecture involves utilizing gateways. These gateways bridge the gap between external protocols (such as FIX) and the internal Aeron Cluster protocol via the Aeron Cluster client.
Advantages of this approach include:
- Client insulation from leader elections: User Interface and FIX Clients (as illustrated in the diagram) remain unaffected by any changes in leadership. Gateways can identify when a leader change occurs and manage any necessary adjustments to the internal state.
- Configuration simplicity: End clients do not need to be aware of the leader's location; they only need to connect to the pre-configured gateway processes. With direct connections, a protocol needs to be added to assist with leader discovery, leader reconnection, etc.
- Scalability: By delegating client and client protocol-specific processing to the gateways, the cluster's capacity can be extended. Tasks such as initial validation, customized fan-out, client-specific data distribution, and client-specific protocol encoding are shifted to the gateways.
Although it may seem that this approach could increase latency due to the additional network hop, typical implementations demonstrate that the most significant contributors to latency are the cluster's business logic, message decoding and encoding, logging, tracing, metrics, and message encryption.
While it is feasible to construct the cluster in such a way that the Aeron Cluster client is run within the same process as the Cluster, and then have clients connect direct to an API, this is not recommended. Note that the Aeron Cluster client is not intended for use in multiple threads.
Consider Pushing Logic to Gateways¶
In certain situations, generating individual messages for each client may be necessary. This can be accomplished in two locations:
- Within the cluster: The cluster computes and transmits all required per-client messages.
- At the gateways: The cluster sends a single message, and the gateways produce the necessary per-client messages.
The cluster-centric method increases the workload on the cluster, consequently reducing its overall throughput.
The alternate approach may require that the gateways hold some state so that they may correctly produce the per-client messages, but by pushing out this processing into the gateways, the cluster throughput is increased.