EVENT DRIVEN ARCHITECTURE/MICROSERVICES

Chronicle Services

Chronicle Services is a framework that is used in the development of high-performance Java Microservices through Event-Driven Architecture. Microservices built with Chronicle Services are efficient, easy to build, test, and maintain. Equally important, they support exceptionally high throughput and low latency processing of events. This offers immediate performance improvements for enterprises and helps future-proof the technology evolution and adaptation to the cloud.

"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

Experience the Speed

To exchange messages as efficiently as possible, it is critical that serialisation to/from the transporting queues is efficient. Chronicle Services can leverage Trivially Copyable messages which allow serializing the object by doing a single memory copy. 

1.5 µs

DTO of primitives in 99.9 percentile

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
Cloud migrations are often multi-year programs that can be quite costly and potentially disruptive. Due to project plans and dependencies, this may also mean that core trading system upgrades are deprioritised until the migration is complete, which can impact performance and competitiveness against other market participants. The solution is a two-stage process. The first step is to break down their monolithic trading systems into microservices. These can then in step two be migrated incrementally to the cloud, with minimal disruption. Read About Cloud Deployment
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.

 

 

Single Threaded

performance

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

Mapping

Multi-way, low latency, replication in a cluster of hosts to support High Availability/Failover and data distribution

Interconnected

routing1

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

control

Upon a restart, the state of a microservice can be re-established by re-reading old messages deterministically.

Scalable Capacity

scale

Easy to add new services with automatic computation of internal state and also to shut down redundant services at any time.

Debuggability

Resilient

Able to replay production data, reproduce production bugs and write tests to reproduce.

 

Single Threaded

performance

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

Mapping

Multi-way, low latency, replication in a cluster of hosts to support High Availability/Failover and data distribution.

Re-established State

control

Upon a restart, the state of a microservice can be re-established by re-reading old messages deterministically.

Interconnect

routing1

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

scale

Easy to add new services with automatic computation of internal state and also to shut down redundant services at any time.

Debuggability

Resilient

Able to replay production data, reproduce production bugs and write tests to reproduce.

Mapping

Robust and Available

Multi-way, low latency, replication in a cluster of hosts to support High Availability/Failover and data distribution.

performance

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.

control

Re-established State

Upon a restart, the state of a microservice can be re-established by re-reading old messages deterministically.

routing1

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.

Resilient

Debuggability

Able to replay production data, reproduce production bugs and write tests to reproduce.

scale

Scalable Capacity

Easy to add new services with automatic computation of internal state and also to shut down redundant services at any time.

NEW FEATURE

Efficient Remote Access to Servers Running Chronicle Services

This feature supports access to services from external clients:

  • Latency as low as 10 microseconds
  • Throughput of one million events per second through a single channel
  • Manage and monitoring functionality
  • Load balancing across multiple service instances
  • 24/7/365 service availability even during service upgrades
  •  Business risk-based data durability guarantees, sync to disk and/or acknowledged replication
Screen Shot 2022-07-29 at 1.01.59 PM

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

How to Develop Event-Driven Architectures

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 a…

Continue Reading >>

Developing Low Latency Trading Systems with Chronicle Microservices

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…

Continue Reading >>

Conference | The Principles of Low Latency Microservices

Peter Lawrey explores how Chronicle Software can help you develop a Low Latency Microservices architecture

Continue Reading >>
What's Next?

Get Started Today

If you want to learn more about how Chronicle Services works, why not start experimenting with our demos or read the documentation? For example, you can learn how to get up and running quickly and how Chronicle Services can be optimised for your environment.