The High Availability Features of Microservices using Chronicle Services

In low-latency microservices, ensuring system resilience without compromising performance is vital. Modern financial platforms demand microservices availability that survives data-centre or availability zone failures, so every microservice must be able to withstand surges of incoming traffic, automatic failover and network partitions while still responding in microseconds. This article explores how Chronicle Services, a Java-based framework optimised for low-latency microservices, meets these critical requirements by integrating HA, performance and data persistence. By combining intelligent load balancing across each availability zone with a design that is inherently fault tolerant, Chronicle Services demonstrates how to achieve availability across multiple regions and minimise downtime during upgrades or incidents, all while keeping latency to an absolute minimum.

Stateful and Stateless Services

A Chronicle Service application consists of a number of processing units known as Services, which interact with each other using events posted on Chronicle Queues. The Chronicle Queue is an extremely fast shared memory inter-process communication; it also has an enterprise version that facilitates replication of queues over the network. Whether your deployment strategy involves a handful of closely-coupled modules or hundreds of distributed services, the framework enables teams to adopt a microservice architecture that scales horizontally with ease, leveraging container orchestration platforms to improve availability and simplify deployment management.

Services can be stateless or stateful; however, the framework’s real strength lies in facilitating stateful service integration without resorting to database dependencies, which are often unsuitable for low-latency requirements. Eliminating external database round-trips not only trims latency but also removes a common single point of failure, further boosting service availability in fault-tolerant deployments. Built-in circuit breakers and configurable rate limits ensure that a misbehaving dependency cannot cascade failures across multiple services, an essential technique for achieving availability in microservices.

Below is an example of a ‘stateful’ service, which requires internal state in order to be able to handle a request. In this example of a Transaction Service, the ‘balance’ in the account would be the state, which needs to be maintained in order to process the incoming requests, and then update the balance.

Diagram 1: Example of a stateful service

In the case of a ‘stateless’ service, state is not required for the service to handle a request. A simple example would be a service that sums up two numbers and outputs the result, as seen below. Stateless workers can be freely scaled behind a load balancer, following anti-affinity rules to distribute replicas across distinct nodes or availability zones for maximum resilience. Continuous health checks feed real-time metrics into the deployment management microservice, allowing proactive scaling when demand increases.

Diagram 2: Example of a stateless service

Persistence in Chronicle Services Applications

Service-to-service interactions in Chronicle Services applications is facilitated by Chronicle Queue, a persistent shared memory-based model for inter-process communication. Chronicle Services utilises Chronicle Queue to provide a “store everything” model, optionally interleaved with periodic checkpointing, ensuring comprehensive logging of all system activities and state modifications.

Chronicle Queue can persist approximately 1 million messages per second, combining efficiency with high throughput. This persistent log acts as an always-on availability service, similar to the durable event streams employed in many service mesh patterns, and forms the backbone of any robust disaster recovery plan.

In the event of an outage, services are able to precisely reconstruct their state by replaying operations from either the input or output persistent queues. Services are thus able to resume precisely from the point of disruption. Data loss is mitigated by adding minimal latency—a few microseconds per message to the queue. In conjunction with blue green deployment practices, teams can stand up a green deployment in a secondary data centre, replay state from the replicated queues, perform dark launching with a percentage of live traffic, and then execute a controlled switchover—a strategy that reduces downtime to near zero.

Queue Replication for High Availability

Chronicle’s High Availability solution is based on replicating the Chronicle Queue instances used to transport messages between services. Suppose a queue instance has been configured to be replicated. In that case, Chronicle Queue Replication copies messages as they are added to a queue to one or more replica queue instances, which may be on different hosts, using Chronicle’s high speed TCP/IP library. Because every message is duplicated across multiple regions or racks, the cluster is highly fault tolerant; even if a host in one availability zone fails, the service can continue from a healthy follower queue without human intervention.

If there is an issue either with the service or a queue, then it can be restarted, or “failed over”, to an instance on a different host where replicas of its required queues exist. As mentioned above, the service will be able to recreate any required state by replaying events from the replica queues, which will contain all of the events that have been duplicated from the primary queue. These circuit breakers ensure that any upstream slowness is isolated, preventing cascading failures throughout the system.

Chronicle Queue Replication operates in the context of a cluster of hosts. Within the cluster, one host is set to host the Primary queue instance, sometimes referred to as the source or leader queue, and the others host Secondary queues, sometimes referred to as sink or follower queues. A service will read and post messages only from/to the source queue. When deployed alongside an Istio service mesh—or a commercial solution such as Tetrate Service Bridge (often referred to as the service bridge TSB)—Chronicle Queue Replication gains additional observability, fine-grained routing, and policy-based circuit breakers.

Diagram 3: Queue Replication

An optional acknowledgement mechanism ensures events are received and stored by at least one secondary host before the replication is deemed successful, thus preventing data loss in the event of a host failure. Engineers may fine-tune this acknowledgement window to balance latency against durability; combined with dynamic load balancers and adaptive rate-limit thresholds, the system maintains peak throughput while safeguarding critical transactions.

Optimising Latency and Reliability

While acknowledgement mechanisms over the network are essential for maintaining data integrity, they naturally incur latency. Chronicle Services mitigates this effect by supporting “in-flight” messages—those that have been dispatched but not yet acknowledged. If enabled, this improves overall latency, balancing performance with looser high availability constraints. Implementing health checks at both the application and container level feeds continuous status signals into deployment management tooling, ensuring that any deviation triggers automatic failover, thereby sustaining service availability and enhancing overall system resilience.

Conclusion

Chronicle Services focuses on resilient, low-latency microservices, efficiently managing stateful and stateless models. It eliminates dependencies on databases for managing service state, using Chronicle Queue for fast data replication and recovery. As organisations continue to adopt distributed systems and sophisticated microservice deployment patterns, these capabilities make Chronicle Services an ideal foundation for achieving availability microservices at scale. By supporting blue green deployment, green deployment rollbacks, dark launching experiments and comprehensive disaster recovery options, the platform empowers teams to deliver new functionality while maintaining superior service availability. Whether you operate a single data centre or span several availability zones, Chronicle’s proven, highly fault-tolerant strategy reduces downtime, protects revenue-critical trading flows and continues to improve availability with each release.