# OpenHFT/Chronicle-Queue

Micro second messaging that stores everything to disk

Repository: https://github.com/OpenHFT/Chronicle-Queue
Canonical: https://ross.abutalabs.com/products/chronicle-queue
Homepage: http://chronicle.software/products/chronicle-queue/
Language: Java
License: Apache-2.0
License Family: permissive
Topics: chronicle, queue, java, performance, low-latency, persistance
Last push: 2026-08-26T22:30:23+00:00

## Health v2 (maintenance only)
Score: 98/100 (v2, computed 2026-09-03T02:20:16.233290+00:00)
- activity 99, release rhythm 95, longevity 100
- inputs: {"age_days": 4840, "days_push": 7, "days_rel": 37, "gap_med": 9.0, "n_releases_24m": 35}
- flags: no_readme
- formula: round(0.45*activity + 0.35*rhythm + 0.20*longevity); archived -> min(score, 10)

## Adoption (not part of the score)
Stars 3797, forks 567 (observed 2026-08-28T04:08:19.994873+00:00)

## What it is
Chronicle Queue is a Java library providing microsecond-latency, persisted messaging that stores every message to disk in an append-only, zero-GC format. It supports deterministic replay and high-throughput inter-process communication, with an enterprise edition adding replication and cross-language support.

## Use cases
- persist millions of messages per second to disk with microsecond latency
- build event-sourced systems with deterministic replay of all messages
- share data between JVM processes with low-latency IPC
- capture audit logs where every message must be durably recorded
- eliminate GC pauses from a trading system's critical path
- replay market data feeds for backtesting

## When to choose
- you need durable, append-only messaging with consistent single-digit microsecond latencies on the JVM
- you require complete auditability and replay of every message
- you're building low-latency trading or financial systems in Java
- you need high-throughput IPC between processes without a network hop

## When to avoid
- you need a distributed broker with multi-language clients out of the box (community edition is Java-centric)
- your throughput needs are modest and a standard message broker like Kafka or RabbitMQ suffices
- you need flexible consumer semantics like competing consumers or per-message acknowledgments
- your data is small-volume and a database or log file is enough

## Facets
- artifact type: library
- maturity: stable
- function: message-queue, serialization, logging, caching
- domain: fintech, performance, developer-tools
- platform: jvm, windows
- tags: low-latency, persisted-messaging, zero-gc, event-sourcing, off-heap, microsecond-latency, messaging, linux, macos

## Member repositories
- OpenHFT/Chronicle-Queue (main) score 98

## Provenance
- Observed fields: from GitHub, fetched 2026-08-28T04:08:19.994873+00:00.
- Health v2: computed from the inputs above; adoption is never an input.
- Inferred fields (summary, facets, guidance): AI-extracted, prompt v1, taxonomy v1, on 2026-08-29T18:26:55.416346+00:00, confidence not recorded.
  - homepage: http://chronicle.software/products/chronicle-queue/ (fetched 2026-08-29T09:21:47.908171+00:00, sha 00f2002abbab)
  - site_page: https://chronicle.software/about-us/leadership-team (fetched 2026-08-29T09:21:47.912383+00:00, sha e9d7b188e3f0)
  - site_page: https://chronicle.software/about-us/company (fetched 2026-08-29T09:21:47.914192+00:00, sha 296425d57f6b)
- Data as of 2026-08-30T08:39:29.467469+00:00.