Aeron and Hydra Platform role in trading platform architecture
This article is the third in a series of four blog posts on Aeron and Hydra Platform:
- Part I: History of Aeron and Hydra Platform. Read here >>
- Part II: 5 trading solutions we delivered on top of Aeron and Hydra Platform. Read here >>
- Part III: Aeron and Hydra Platform in a trading platform.
- Part IV: Operating Aeron and Hydra Platform based solutions. Read here >>
Now that we looked at some of the projects we delivered with Aeron and Hydra Platform, I am going to give more details about Hydra Platform.
Hydra Platform is a suite of components we use to complement Aeron and Aeron Cluster and to accelerate and de-risk the development of trading systems for our clients. Hydra Platform provides libraries and tools for developers and also a set of operational tools.
Development accelerators
It is easier to introduce Hydra Platform in the context of a real solution, I will use the architecture of an exchange we built for one of our clients.
The following diagram highlights some of the key components of the architecture - several services and gateways are omitted to keep things simple.
Aeron and Aeron Cluster are represented in green on the diagram. The dark blue components represent the Hydra Platform stack. Finally, the light blue represents the bespoke business logic we implemented on top of Hydra Platform for this exchange.
What follows is a brief overview of the different services and gateways composing the platform and the underlying Aeron and Hydra Platform components:
Aeron
Aeron is used as an internal messaging system. It connects the different services using a mix of unicast and multicast UDP traffic. We leverage Aeron delivery guarantees, its flow control capabilities and Aeron archive in various places of the architecture for persistence and replay capabilities. Aeron provides all the functionalities we expect from a mature messaging system and has excellent performance characteristics.
Clustered matching engine
The clustered matching engine is the core service hosting the matching engine and the risk engine. It consists of:
- Aeron Cluster provides fault tolerance. It sequences and replicates messages coming from various services and gateways to the matching engine. It implements fault detection and failover (leader election protocol based on RAFT). It also provides durability by persisting the ingress log and snapshots. Aeron cluster tackles one of the hardest problems in distributed system engineering: a plug and play fault tolerant container.
- Hydra Platform Repositories: another challenge developers face when developing low-latency trading systems is how to manage state efficiently and achieve durability. The Hydra Platform Repositories component manages application in-memory state. Hydra Platform Repositories is a compiler. It takes a definition of the state schema we hold in the service and emits a set of repositories via code generation. These repositories hold reference data and all state maintained in the service in off-heap storage (memory mapped). This facility enables developers to implement allocation-free state management and gives us snapshotting without any additional dev effort. Repositories are capable of snapshotting and re-hydrating state automatically, and this works hand-in-hand with Aeron Cluster for service durability. The tooling also includes facilities to migrate snapshots, allowing us to upgrade snapshots when releasing new versions of the exchange.
- Hydra Platform Codecs solves another set of problems: how to efficiently communicate between services while keeping a highly productive developer experience? Hydra Codecs is another compiler which takes the definition of messages exchanged within the system and generates binary encoders and decoders. It is a “gRPC on steroids” and generates services proxies that we inject in the various business logic modules to send and receive messages asynchronously across the platform. It is entirely allocation free and very efficient (an order of magnitude more efficient than Google protocol buffers, for instance) and works on top of Aeron and other transports such as WebSockets. This forms our messaging fabric for both server and client side. The compiler is able to emit TypeScript code for the browser which allows us to use the same binary protocol end to end, from a trading or admin UI up to the service layer.
- Hydra Platform Persistent Egress forms a persistent event log. It is built on top of Aeron and Aeron Archiver and allows the match engine to distribute market data and other events to subscribed components. Messages are persisted to disk and can be replayed by subscribers, allowing them to catch up, for instance, if they get disconnected or restarted.
- Risk Engine & MatchingEngine are core modules that implement the business logic of a venue. They are implemented in Java and leverage the underlying components previously mentioned.
Venue Historical Service (VHS)
This service selectively records egress messages of the matching engine to a database, providing an easy queryable buffer of the last few weeks of orders, trades and other audited events. The VHS consumes the egress stream of the cluster and is able to recover following a fault, thanks to the persistent egress.
FIX Order management, market data and drop copy
These gateways, while playing different roles have a similar architecture:
- Hydra Platform Cluster client handles connectivity to the cluster and reconnection logic after a network failure or server fault.
- Hydra Platform Codecs: gateways use code generated codecs to interact with the core cluster and other services in the platform
- Business logic: custom business logic is hosted in the gateways, essentially mapping external to internal protocols.
- Hydra Platform FIX Gateway: this Hydra Platform component, based on Artio, implements FIX session protocol and encoding/decoding of FIX application protocol.
Admin Web Gateway
Admin Web Gateway provides connectivity to the administration UI used by market operators. It leverages the following components:
- Hydra Platform Cluster client and internal Hydra Platform codecs already mentioned before
- Hydra Platform UI codecs: this leverages Hydra Platform codecs to generate the UI to server protocol over WebSocket. As previously mentioned we use the same technology end to end for UI to server communication and server to server communication from an encoding perspective.
- Hydra Platform LiveQuery: this Hydra Platform component works hand-in-hand with UIs and includes client and server side components. It allows a UI to send a query to the server, and the server can then service this query by sending a snapshot and then keeping the data set in sync as data “ticks”. For instance, our trade blotter is underpinned by LiveQuery, like all blotters and several other views of the administration UI. When the user filters, sorts or scrolls in the blotter, LiveQuery sends a query to the server which evaluates the query, sends back the section of data (viewport) the user is looking at and then streams any change to the data set. This is a very convenient tool, as many user interfaces in trading can be represented as a tabular data set. We see large performance gains achieved by LiveQuery, because the client does not need to hold the entire set of queryable state in memory whilst achieving efficient filter/query operations.
- Hydra Platform WebGateway is a high performance WebSocket server that we use to connect UIs and API clients. It can sustain a large number of concurrent connections, high loads and is optimised for low latency delivery of messages to/from clients. It also offers pluggable authentication (generally via Single Sign On) and the various features you expect from such gateway (rate limiting, session management, message delivery to groups of sessions, WebSocket fallbacks, etc)
Admin UI
This user interface is used by administrators to operate the system (market operation). The UI consists of the following components:
- Hydra Platform Transport: this component manages connectivity to the WebGateway over WebSocket, including disconnection detection and reconnection.
- Hydra Platform LiveQuery: this is the client side counterpart of Hydra Platform LiveQuery, previously described. This component also integrates with ag-grid directly, allowing us to quickly build blotters and various grid based views.
- Hydra Platform UI Codecs: our compiler generates TypeScript classes allowing the UI to send and receive binary messages over the WebSocket transport. The advantage with this type of approach is that it allows our UI and backend developers to agree to contracts quickly and then generate service proxies. Also, when the contract changes server side we can detect immediately breaking changes in the UI thanks to TypeScript's strongly typed system.
In part four of this series we will look in more details at the operational aspects of running such trading systems and the tools we have built as part of Hydra Platform
The series is also available for download as a white paper. In this paper, we provide an overview of Aeron & Aeron Cluster, and look at some of the projects we have developed using Aeron during the past 3 years. We then provide an overview of Hydra Platform which contains some of the building blocks we produced to complement Aeron and further accelerate the development of systems we build. While we do not go into deep technical details, this document is particularly suited for developers, architects and CTOs.
Olivier Deheurles
Co-founder and Chief Technology Officer,
Adaptive Financial Consulting
