Developing Low Latency Trading Systems with Chronicle Microservices

Peter Lawrey 14th April 2021

Introduction to Chronicle Services

Traditionally, low latency trading systems were developed as monolithic applications in low level languages such as C++. While these systems delivered the required performance, the development effort was extremely time consuming, and the complexity of the software made it difficult to adapt existing applications to changing market demands.

A solution to these problems is a low latency microservices framework developed using a programming language that provides both accessible code readability and, when concisely tuned, performance near to bare machine levels.

The Chronicle Microservices Framework is a Java microservices platform with particular emphasis on low latency and maximum performance. Systems built with Chronicle software are typically deployed into latency-sensitive environments where the end to end process across multiple microservices  is within 30 microseconds, with 99% of responses generated within 70 microseconds, these numbers include extensive client business logic

Companies large and small in a wide range of industries employ open source Chronicle software to improve the performance of their applications and lower application latency. Examples of these industries include Financial Markets, Artificial Intelligence, Logistics, Gaming, Manufacturing, Payments and IOT amongst others. However, with most of the top 100 global banks using Chronicle to develop low latency trading systems this remains our principal focus.

Meeting these requirements of high performance combined with very low latency requires careful attention to all aspects of coding and architecture. Chronicle’s software is highly optimized Java, employing techniques that minimize operating system overhead and Java Garbage Collection (the objective is zero GC). The services are single-threaded, eliminating the need for thread management, locks, signals, polls of thread state, etc. This produces a deterministic and reproducible result (critical for replicating and debugging problems), while also increasing throughput and decreasing latency.

The model for Chronicle microservice design is Lambda Architecture:

 

The microservice function receives events from a source of data that contains the complete history of all events and operates in an append-only manner. The microservice reacts to the events, processes the input data, and generates output data. In many cases, the function is stateless: all required information is derived from the input events. However, in some cases efficiency is gained by maintaining some state between transactions. High performance and low latency are the objectives that determine whether a particular Chronicle service maintains some state or is stateless. If state is maintained, it can be persisted to reduce start-up time the next time the service is launched.

A low latency microservices approach also provides greater flexibility than the monolithic approach when the need arises to adapt operational systems to new circumstances.

Example low latency trading system

The diagram below represents an example trading system. The system consists of configuration scripts, microservice components, input data streams, output data streams, and communication between the individual microservices.

In brief, processing is initiated by input orders processed by an order management system (OMS). The OMS creates order events that are passed to fix and position microservices. The fix service interacts with both the order service and a bookbuilder service. The bookbuilder service outputs data to the position and pricer services. The pricer service can also interact with the position service.

Each microservice receives an input configuration and input data, then produces output data that is consumed by other services and/or reviewed by a human. A common performance problem that arises when microservice suites are integrated to create an application is slow communication between the microservice components. No matter how fast and efficient the individual services are, if inter-microservice communication is a bottleneck, overall application performance will be slow.

Chronicle Queue, a memory mapped file that is shared between microservices in an application, solves this problem. It’s structure provides extremely rapid transfer of large amounts of data between microservice components without impacting system performance. There is no Garbage Collection, because everything is done off the heap.

Data is readable by the recipient microservice in single digit microseconds after it is written. Concurrent writers can be activated across processes running on the same machine, facilitating scaling of individual microserver processing as needed. Queue also persists every data value to disk, providing the capability to replay events of interest at a future time.

Order service

The processing in a trading system is initiated when an order event occurs. The order event might be generated by the actions of a counterparty, a portfolio manager, an automated hedging system, or some other type of algorithmic model.

Chronicle FIX Engine

The Chronicle FIX Engine provides scalable high throughput FIX services with available failover to a hot server via replication. The service supports all versions of FIX. All messages are available for replication.

The service is designed for use in trading systems that require ultra low garbage collection (less than one minor GC per day). In addition, to achieve high performance at low latency, the engine employs:

  • Zero copy: eliminates unnecessary garbage collection and increases speed.
  • Runtime code generation: reduces code size for efficient CPU cache usage and increased speed.
  • Smart ordering: optimizes parsing and increases speed.

Chronicle FIX Engine parses and generates 100,000 medium sized FIX messages (for example, NewOrderSingle and ExecutionReport) per second. Message processing in either direction takes around 1 microsecond 99.9% of the time.

Position service

The Chronicle PositionManager calculates positions and equivalent positions based on market rates. Positions can be aggregated at different book levels to produce a global position across the entire firm. The PositionManager service performs risk management, computing VaR and PnL based on inputs from the Chronicle Bookbuilder service or a custom service.

Bookbuilder service

Chronicle Bookbuilder service can input pricing data from multiple sources, both market data increments, and market data snapshots. The service uses the input data to build pricing ladders that can be configured per venue or aggregated into multi-venue books. For example, the ladder depicted below represents a single market. Chronicle Bookbuilder can aggregate ladders from multiple markets and create a comprehensive global view of all bid/ask pricing and the volume available at each price.

The Chronicle Bookbuilder ladder depth is configurable all the way to unlimited depth, providing a picture of the entirety of available volume in the marketplace. Throttling based on price movements can be implemented to limit rapid output to pricing and position services in highly volatile markets. Core Chronicle Bookbuilder processing has been benchmarked at under 1 microsecond.

 

Pricer service

In this example, Bookbuilder data is sent to the Chronicle Pricer service, which facilitates integration of custom pricing algorithms into Chronicle’s high throughput trading infrastructure. The Pricer also takes position data from the PositionManager service. In a live FX trading system benchmark, Pricer supported more than 50K market data messages per second. Output prices can be consumed by other software, published to a user interface, or directed to an API.

 

Additional Chronicle Microservice Capabilities

The speed and low latency of Chronicle Queue significantly improves failover capability: if a warmed up server is available and a failure on the mainstream server occurs, Chronicle Queue rapidly transfers the current input data stream to the failover server, with little increase in overall system latency.

 

If a particular state of processing is a bottleneck for the trading system, Chronicle Queue can be used to quickly transfer portions of the work to additional servers, substantially lowering the latency accountable to that processing stage.

 

Playback of events that initially occurred in real time is another important feature of the Chronicle Microservices approach. All messages that have passed through each processing stage are stored in perpetuity. This enables replicating the data flow through the system at a later date, which facilitates:

 

  • Diagnosing and fixing bugs in any part of the system, using the same data that caused the original anomaly.
  • Examining behaviour with actual data to identify potential algorithmic or data flow improvements.
  • Testing and refining prospective performance improvements using production data rather than simulated data.

 

Testing is facilitated by the capability to configure business logic describing how each service will run using the human readable mark-up language YAML. A system designer who understands the functionality of each service can readily tailor that functionality to address the specific needs and purpose of the overall application.

 

Conclusion

The Chronicle Services software facilitates the creation of high-performance, high throughput, scalable low latency trading systems that provide rapid failover and the ability to play back past events using the live data that went into the processing. The software is designed for straightforward integration with existing custom software systems, providing customers with the opportunity to utilize the Chronicle platform to significantly increase the performance and throughput of their algorithms while substantially reducing latency.

The table below summarizes benchmarked performance for the Chronicle microservice components discussed above.

 

Component Performance
Chronicle Queue 1 microsecond to read a message; 1 microsecond to write a message. 1 Million messages per second in either direction.
Chronicle FIX Engine Parses 100K medium sized messages (e.g., NewOrderSingle or ExecutionReport) per second; generates 100K medium sized messages per second. Message processing takes about 1 microsecond 99.9% of the time. Less than 1 minor GC per day.
Chronicle Bookbuilder Benchmarked at under 1 microsecond.
Chronicle Pricer Supported more than 50K market data messages per second in a live FX trading system benchmark.

Chronicle Software provides low latency Java Microservices designed to meet the needs of the trading community. By providing both the infrastructure and expertise, our approach delivers trading applications which can perform on par with C++, with a significant reduction in time to market, readily adaptable by a company’s skilled Java developers, and providing the agility to continue to keep pace with changing regulatory and market demands.

 

Find Out More

For more information, and opportunities to download and test the Chronicle Microservices platform, contact the Chronicle Software team

Want access to exclusive Chronicle content?

The Chronicle Community is now live, hit the button below and join the community, for free! You'll get exclusive access to blogs, guides and video content. Join today!

Want more from Chronicle? Subscribe today!

Something went wrong. Please check your entries and try again.