Distribution, Scalability, and HA/DR

Throughout the preceding discussion emphasis has been placed on the modular and hierarchical nature of the design:

• The core per-symbol Order Book

• Processing Pipeline with 1 or more Order Books per Matching Engine

• 1 or more Matching Engines, with Aggregating services providing global views

• All coupling between hosts based on replicated Queues

• Distributed cluster of client gateways

This approach provides great flexibility in how components are distributed over available hosts, and can be freely scaled as needed to match growth in demand.

All state required by an individual component is contained in the component’s Queue, and the Queue can be replicated in real time to any number of hosts, which in turn provides considerable flexibility for HA/DR options. Replication can optionally be configured to require acknowledgements from some or all of the secondary instances which minimises the risk of message loss at the cost of higher latencies. This aspect is again freely configurable, so parts of the system which demand the highest latencies but can tolerate some potential message loss can be run without acknowledgement, whereas other parts of the system which demand no message loss but which are less latency sensitive can run with acknowledgement. Chronicle Queue Enterprise allows acknowledgement strategies to be customised based on message content e.g. ensure that a large order is replicated (and acknowledged) by n hosts.

In this model also, only a single component is responsible for appending data to any one Queue. Once a Queue is available on a host, any number of services can read data from the Queue completely independently. This in turn allows - for example - multiple aggregation services on one host to be driven off a single replicated copy of the set of queues from the Chronicle Matching Engine instances. Going the other way, multiple services can be run on the same host as the source Queue without the need for replication: all that is required is access to the Queue data. The number of Queue readers does not impact write performance.

The diagram below illustrates the main components of a typical full exchange environment. Components within the shaded grey boxes can be arranged arbitrarily across any number of hosts to match available resources. The entire environment is then replicated to a secondary DR site. The DR site will require the same components as the primary in one-to-one correspondence, but these components may be arranged across available resources independently of the primary arrangement.

Clients can connect to any available gateway. Gateways in the secondary site will not accept any connections until the site becomes primary.

Minimal Environment

A minimal exchange environment demonstrating core matching functionality with all symbols supported in one Matching Engine (but neither Drop Copy nor Market Data services) can leverage the flexibility of the design to collapse the client gateway and Risk Aggregation services into the same environment/host as the Chronicle Matching Engine instance, providing a fully self-contained package. The components remain coupled via Queues, and replication to a secondary instance remains as above.