Description of the process of creating an online trading system architecture: hedge fund analyst approach

We write a lot about the creation of trading systems and create tools for their development (from the brokerage system API to the designer of robots inside the trading terminal ). Today we will discuss the design of the architecture of the alaorhimic trading system - the material from the Turing Finance blog, written by NMRQL hedge fund analyst Stuart Reed, is devoted to this topic.

In his article, the author describes the principles of creating an architecture for a trading system that would meet the requirements of ISO / IEC / IEEE 42010 and standards for describing software of engineering architectural systems. According to these standards, the description of the architecture should contain various standardized architectural approaches and support links between design solutions and system requirements. We present to your attention an adapted translation of this article.
')

Choosing software

Disputes about the fact that there is a system architecture, are still ongoing. In the context of the topic of the article, the author proposes to understand by this the internal infrastructure, the application components of which satisfy the functional requirements, can be installed, deployed and launched. Non-functional requirements can be assessed through the quality of the system itself.

Even if all the functional requirements are met, this does not mean that the system is built with high quality. Non-functional requirements should also be taken into account. We illustrate this idea with an example. Imagine the following picture: the trading system that you have just acquired or independently built is making the right trading decisions. But it is arranged in such a way that neither risk management organization nor accounting reports can be entrusted to it. It is unlikely that such a system can be called fully satisfying.

Architecture concept

At the abstract level, the concepts and basic mechanisms of the system are described. It is desirable with deep and detailed study. At this stage, the trading system is “packaged” into the Event Driver Architecture. That, in turn, is divided into 4 layers and two separate approaches. For each of them their own references and patterns are used. Patterns are generally accepted structures for achieving specific objectives.

An event management architecture is an architecture that allows you to detect, produce, and destroy events or respond to them. Events can be: real-time market movements, complex events or trends, trading signals that are streamlined in one way or another.

The concept of the trading system architecture is shown in the picture:

Reference Architecture

If you use the construction metaphor, then the reference architecture is the same as the design of the bearing wall. It can be used to create rooms of various designs. The main thing - it satisfies the basic requirements of building standards. The reference architecture is a kind of model that describes the general structures and mechanisms that are fashionable to use to create a specific architectural software with specific requirements.

The architecture for an algorithmic trading system uses the spatial architecture (SBA) and the fundamental model-view-controller (MVC) pattern as references. Practices such as the operational data warehouse (ODS), the “extract, transform, load” pattern (ETL) and the corporate data warehouse (Data Warehouse) are also suitable.

Model-view-controller - a pattern that divides the application model, user interaction and interface into three separate parts.
The spatial architecture establishes the infrastructure in which the poorly interconnected elements of the process interact through the allocated associative memory (picture below).

Model view controller

Spatial architecture

Structural approach

At the construction stage, the components and sub-components of the trading system are determined. The framework defines how these components will be deployed within the physical infrastructure. A UML diagram (a diagram in a unified modeling language) shows which components are included and how they are deployed. The figures show deployment diagrams: common and for each of the layers.

Architectural Tactics

Tactics deals with the qualitative attributes of a model. The simplest example of how the system tries to adapt to quality requirements is the manipulation of an operational data set through continuous queries. These components are able to continuously analyze ODS to detect and extract complex events. Here is a list of tactics that are used in architecture:

Disintegrator pattern in the event queue.
Allocated memory for the queue and event order.
Continuous Query Language (CQL) for ODS.
Data filter for incoming information.
Algorithms for the distribution of incoming and export connections to bypass congestion.
Active Queue Management (AQM) and congestion notification system.
Calculation of resources consumed with the ability to scale the system.
Active redundancy for every single fault.
Indexing and optimization of resilient structures in ODS.
Schedule regular backups and cleanup scripts for ODS.
Transaction history to all databases.
Checksums for each row for error detection.
Annotation of events with time stamps for ignoring obsolete events.
Establish order confirmation rules for the maximum number of trading events.
Automated trading components use memory-based databases for analysis.
Two-level authentication in the user interface to activate the connection.
Encryption in the user interface to connect.
Observation pattern for managing MVC views.

This list offers only a small number of design solutions that the author of the article was able to identify during the development of the architecture for the trading system. The list is far from complete. At each level of detail, new tactics are added to meet the functional and non-functional requirements. The picture shows three diagrams describing the disintegrator pattern, filter pattern, and continuous query components:

"Behavioral" view

This architecture overview demonstrates how the components and layers of the system should interact. It is very useful when you develop scripts to test the system and understand how everything works from beginning to end. This review consists of sequence diagrams and activity diagrams. The latter show the internal processes of the trading system and how the traders themselves interact with it. Examples of such diagrams are presented below.

Techniques and frameworks

The final step in developing the architecture of the software part of the trading system is to find suitable techniques and frameworks that can be used to implement it. The general rule here is: try to squeeze everything out of the existing techniques for a start, making sure that they meet functional and non-functional requirements. The framework in this case is a reference architecture. For example, the JBoss framework implements the JEE reference architecture. Here is a list of several techniques and frameworks that can be used to create a trading system architecture:

CUDA is a product of NVidia. She has several products at once that support high performance for computing in financial modeling. You can achieve a 50-fold increase in performance, for example, to simulate a Monte-Carlo on a GPU instead of a CPU.
Apache river is a set of tools for building distributed systems. It has found applications as a framework for applications based on the SBA pattern.
Apache Hadoop - this tool offers interesting solutions for big data problems. It can be deployed in a cluster environment to support CUDA technology.
AlgoTrader is an open access algorithmic trading platform. It can be deployed where automated trading components are located.
FIX Engine is a standalone application that supports financial information exchange protocols (FIX, FAST and FIXatdl).

It should be remembered that any components (techniques or frameworks) must have an API to ensure their compatibility.

Conclusion

The proposed version of the architecture satisfies the most general requirements of algorithmic trading systems. For such systems, three factors bear the main load, which act in practice in different combinations:

Dependence on the external environment and exchange systems.
Non-functional requirements.
The evolution of architectural constraints.

The proposed architecture needs to be adapted based on movement from case to case. It must meet specific organizational, regulatory requirements and regional restrictions. Simply put, the article presented only a list of useful links that still need to be customized for individual needs.