Gateway distribution

Summary

Individual users often require views customized to their permissions. Shifting the logic used to customize messages from the cluster to a gateway can improve throughput, at the cost of reduced fairness and increased static data replication.

Valid scenarios:

• Systems which require a high degree of customization. Some systems do not need any customization.
• Anytime absolute fairness is not a legal or regulatory requirement.

In a typical trading system, the UI of different users will often need to see different views on the same underlying data. Using an example of a broker dealer platform, a dealer view of the negotiation will likely differ greatly from the view of a trader taking part in the same negotiation. This customization of messages can become costly as the number of connected clients increases into the hundreds.

Information leakage and security concerns mean that every message on the wire to the client must hold the exact data allowed to be visible by that client. What approaches do we have to improve this?

Approach 1: Have the cluster customize the messages

This approach is the simplest but will become a bottleneck as user numbers and/or message complexity grow. Construct all required customized messages for the UI to consume inside the cluster during a duty cycle. Each message is then sent to the correct gateway which in turn will send it on to the connected client. In some systems with many users logged in, this can result in customization of thousands of individual messages. While Aeron Cluster is producing these custom messages, it cannot consume the next inbound message, and as a result, cluster throughput falls.

Due to the simplicity, it is typical for this approach to be used early in a trading system's development.

Approach 2: Shift the logic into the gateways

This approach requires a lot more groundwork, typically including a framework for static data distribution. Build the UI to hold key static data within an in-process store to reduce the need to move slowly changing static data over every message.

Tip

This approach can introduce unfairness to gateways as heavily loaded gateways will delay messages when compared to lightly loaded gateways. To prevent any unfairness, use a single gateway. To add resilience in this scenario, keep a second gateway warm but inactive.

To shift the distribution logic into the gateways, the cluster broadcasts data for a new state in the state machine. Included with this state change is all the required input data for the customization process. Each gateway customizes the messages for every user connected to it. Messages should reference static data already sitting in a store within the UI.

This approach can introduce invalid data for short periods of time, depending on how you manage your static data. If static data is running via the cluster, there should be no issue; if, however, your cluster has no or limited static data, and static data is instead replicated to the gateways via another route, then the possibility of a race condition exists.

With this in place, the cluster can continue processing inbound messages while gateways are customizing outbound messages. Add gateways to achieve scale-out scalability.