"Chronicle Services laid a great foundation down for us to build our trading algorithms on top of"
- Jeff Gomberg, Head of Electronic Trading at StoneX Markets LLC
Single Threaded
Each microservice can be run single-threaded on a dedicated thread via thread affinity. There is no need for locks, monitors, or concurrent data structures.
Robust and Available
Multi-way, low latency, replication in a cluster of hosts to support High Availability/Failover and data distribution
Interconnected
The microservices are interconnected via Chronicle Queue which records all messages. This provides a low latency audit trail of processed events -no additional logging is required.
Re-established State
Upon a restart, the state of a microservice can be re-established by re-reading old messages deterministically.
Scalable Capacity
Easy to add new services with automatic computation of internal state and also to shut down redundant services at any time.
Debuggability
Able to replay production data, reproduce production bugs and write tests to reproduce.
Single Threaded
Each microservice can be run single-threaded on a dedicated thread via thread affinity. There is no need for locks, monitors, or concurrent data structures.
Robust and Available
Multi-way, low latency, replication in a cluster of hosts to support High Availability/Failover and data distribution.
Re-established State
Upon a restart, the state of a microservice can be re-established by re-reading old messages deterministically.
Interconnect
The microservices are interconnected via Chronicle Queue which records all messages. This provides a low latency audit trail of processed events -no additional logging is required.
Scalable Capacity
Easy to add new services with automatic computation of internal state and also to shut down redundant services at any time.
Debuggability
Able to replay production data, reproduce production bugs and write tests to reproduce.
Robust and Available
Multi-way, low latency, replication in a cluster of hosts to support High Availability/Failover and data distribution.
Single Threaded
Each microservice can be run single-threaded on a dedicated thread via thread affinity. There is no need for locks, monitors, or concurrent data structures.
Re-established State
Upon a restart, the state of a microservice can be re-established by re-reading old messages deterministically.
Interconnect
The microservices are interconnected via Chronicle Queue which records all messages. This provides a low latency audit trail of processed events -no additional logging is required.
Debuggability
Able to replay production data, reproduce production bugs and write tests to reproduce.
Scalable Capacity
Easy to add new services with automatic computation of internal state and also to shut down redundant services at any time.
Why Use Chronicle Services?
Traditionally, low latency trading systems are developed as monolithic applications in low-level languages such as C++. While these systems deliver the required performance, the development effort is high, and the complexity of the software can make it difficult to adapt existing applications to changing market demands.
A solution to these problems is to use Chronicle Services, an event-driven microservices framework that provides simple, maintainable, testable code and incredible performance.
Tailored Microservices
Chronicle Services is the perfect starting point to develop tailored solutions. The Chronicle team has helped develop custom microservices for individual firms, such as solutions for pricing, auto hedging, order management, or market connectivity. There are also ready-made microservices, e.g. Book Builder and Market Gatekeeper that can be deployed in conjunction with Chronicle's performance optimised FIX-engine. See Chronicle EFX
Cloud Migration
Solution to Microservices Latency Problem
The downside to many microservices architectures is extra latency. Microservice-based architectures require additional infrastructure to connect all the components, and for trading systems, this can end up adding milliseconds of messaging latency between microservices. Chronicle Services utilises a low-latency persistent messaging between microservices, that introduces only low microseconds of latency.
Proven in the Most Demanding Environment
When it comes to high-frequency messaging, one of the most demanding environments is foreign exchange (FX). The requirements are to be able to process billions of high-frequency messages a week with the lowest possible latency. Chronicle Services is proven on this market globally and therefore the perfect choice not only for FX solutions but for other industries and demanding applications as well.
Licensing and Support
At Chronicle we pride ourselves on the stability and knowledge of our development and support team. With decades of experience from the financial industry, you can trust us with your toughest challenges.
Complete Control of the Code
All customers get full access to our GitHub repository where you can read, fork, and create pull-requests on the Chronicle Services source code. This means you have complete control over your environment and the freedom to continually optimise your workflows.
Get Expert Help
Our expert consultants are ready to support you with any issues that may arise. Chronicle Services is a part of a system, and our experienced developers can help with architecture and latency issues in other areas if needed.
Simple Licensing Model
Our simple and transparent licensing model provides certainty and ensures that Chronicle Services is available to businesses of all sizes, from the largest bank to the smallest hedge fund.
Articles about Chronicle Services
Last month, I wrote an article on Open source Chronicle Wire, that discusses how we could serialise an application’s state into different message formats. Now in this article, I’m going to look at how we can use Open source Chronicle Queue and Chronicle Wire to structure applications to use Event-Driven Architecture (EDA). EDA is…
I wrote an article on low latency microservices almost five years ago now. Chronicle Software has worked with a number of tier one investment banks to implement and support those systems. What has changed in that time and what lessons have we learnt? Read this article and learn what we learned after five years of developing…
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…