Low-Latency Messaging for Capital Markets: Aeron vs Kafka vs Chronicle Queue

If you are building a trading system, the choice of messaging layer is the single most consequential infrastructure decision you will make. Pick the right one and your trading desk gets real-time market data with predictable microsecond latency. Pick the wrong one and you will spend years fighting garbage collection pauses, backpressure bottlenecks, and missed trade opportunities.

We have deployed all three of these messaging systems in production at tier-one banks — Aeron for exchange gateway connectivity, Kafka for settlement and risk workflows, and Chronicle Queue for deterministic journaling on the trading floor. Here is what we learned.

Who Is This Guide For?

This guide is for trading system architects, quantitative developers, and infrastructure engineers evaluating messaging technology for capital markets environments. If you are designing an OMS, market data pipeline, or algorithmic trading platform and need to understand the real-world latency and throughput characteristics of each option, this is for you.

By the End of This, You’ll Know…

• The fundamental architectural differences between Aeron, Kafka, and Chronicle Queue
• What latency profiles each system delivers at P50, P99, and P99.9 under trading workloads
• Which protocols and deployment patterns work best for specific use cases
• How we have deployed each in production at regulated financial institutions

The Three Architectures

Aeron — UDP-Based Multicast for Extremely Low Latency

Aeron is not a message broker — it is a low-latency messaging library that uses UDP multicast and unicast with efficient loss recovery. It was designed by Martin Thompson, creator of the LMAX Disruptor pattern, and is maintained by the Real Logic team at Adaptive Financial Consulting.

Aeron’s key design decisions:

• UDP transport: No TCP overhead. No reconnection logic. Messages flow directly between sender and receiver with minimal kernel involvement.
• Media Driver: A dedicated agent that handles all network I/O in a separate thread, so application code never blocks on sends or receives.
• Loss recovery via NAK: Lost packets are detected and retransmitted at the application layer using a Negative Acknowledgement protocol, which is faster than TCP’s retransmission logic for trading workloads.
• Embedded or standalone: The Media Driver can run in-process or as a separate daemon, depending on your isolation requirements.

In production, Aeron delivers sub-10 microsecond P50 latency between two machines in the same rack, with P99 under 50 microseconds when properly tuned. We have used it to connect order management gateways to exchange-facing FIX engines, where deterministic latency matters more than throughput.

Kafka — Durable, Persistent Messaging for Settlement and Risk

Apache Kafka is a distributed event store designed for high-throughput, persistent messaging. Unlike Aeron, Kafka persists every message to disk and replicates across brokers for fault tolerance.

Kafka’s architecture:

• Persistent append-only log: Every message is written to disk, so brokers can survive crashes without data loss.
• Partitioned topics: Throughput scales horizontally by adding partitions across multiple brokers.
• Consumer groups: Multiple consumers read from the same topic without coordination overhead.
• Exactly-once semantics: Transactional producers and idempotent writes provide strong delivery guarantees.

Kafka’s latency profile in capital markets contexts is 2-10 milliseconds at P50 — orders of magnitude slower than Aeron — but its strength is durability and replayability. We use Kafka for settlement workflows, trade confirmation matching, and risk position aggregation, where losing a message is unacceptable and millisecond latency is acceptable.

Chronicle Queue — Deterministic Journaling for the Trading Floor

Chronicle Queue is a low-latency, persistent Java library that writes directly to memory-mapped files. It was designed by Peter Lawrey and is maintained by Chronicle Software.

Chronicle’s unique approach:

• Memory-mapped files: Writes go directly to off-heap memory, bypassing the garbage collector entirely. This eliminates GC pauses, which are the enemy of deterministic trading applications.
• Append-only journal: Every message is appended to a queue file on disk. There is no broker, no network, no serialization overhead for same-process communication.
• Deterministic performance: Chronicle’s latency is predictable because the allocation-free, GC-free path eliminates jitter from garbage collection pauses.

In production, Chronicle Queue achieves sub-microsecond P50 latency for same-process communication, with P99 under 5 microseconds. We have deployed it as the journaling layer for audit trails and order capture, where every trade must be recorded with nanosecond timestamps and zero allocation overhead.

Performance Comparison

These numbers represent observed performance in production deployments at tier-one banks, measured across two machines in the same rack with 25 Gbps connectivity:

Aeron and Chronicle serve different purposes. Aeron is for network-connected microsecond messaging. Chronicle is for same-process or same-host nanosecond journaling. Kafka is for everything that needs to survive a data centre failure.

When to Use Each in Capital Markets

Aeron for Exchange Connectivity

If your trading system needs to send orders and receive market data from exchange gateways at microsecond speeds, Aeron is the right choice. We have deployed it as the transport layer between order managers and FIX gateways, where deterministic latency is non-negotiable.

Aeron works best when:

• Senders and receivers are on different machines (gateway architecture)
• Your application tolerates ephemeral messaging (no persistence)
• You can tune the Media Driver with dedicated CPU cores for low jitter
• Loss recovery via NAK is acceptable for your workload

Kafka for Settlement, Risk, and Operations

Kafka is overkill for exchange-facing messaging, but it is the right choice for the back-office and middle-office systems that need reliability over speed. We use Kafka to stream trades from the OMS to settlement systems, risk engines, and data warehouses.

Kafka works best when:

• Messages must survive broker failures (data centre outages, network partitions)
• Multiple downstream systems consume the same events independently
• You need replayability for audit and regulatory purposes
• Throughput in the hundreds of thousands of messages per second is sufficient
• Your latency SLA is in the low milliseconds, not microseconds

Chronicle Queue for Audit Trails and Order Capture

Chronicle Queue excels where Aeron and Kafka cannot go — inside the same process, with zero allocation, zero GC, and deterministic latency that satisfies regulatory audit requirements.

Chronicle works best when:

• You need persistent journaling of every trade, quote, or order event
• The journaling layer runs in the same process as the trading engine
• GC pauses are unacceptable (Chronicle avoids allocation entirely)
• You need sub-microsecond, deterministic write latency with file-backed durability

For a deeper technical comparison of Aeron and alternative messaging systems, see our colleague’s analysis on Aeron vs Other Queue Implementations.

Production Patterns We Use

Pattern 1: Aeron → Kafka Bridge

Many tier-one banks use Aeron for exchange gateways and Kafka for downstream distribution. The pattern:

1

[Exchange] → Aeron Gateway → Transform → Kafka Topic → OMS, Risk, Settlement

The Aeron gateway receives market data and order execution reports with microsecond latency. A transform layer enriches and normalises the messages into the firm’s canonical schema. The enriched messages are published to Kafka topics, which multiple downstream systems consume independently.

Pattern 2: Chronicle Queue for Trading Engine Journaling

For trading engines that generate hundreds of thousands of orders per day, regulatory auditors require a complete, tamper-evident record of every event. Chronicle Queue provides this without impacting trading performance:

1

[Trading Engine] → Chronicle Queue (audit journal) → Replay → OMS

The trading engine appends every event to a Chronicle Queue file. The queue file serves as the single source of truth for order events, market data snapshots, and risk state changes. On restart, the engine replays from the queue to recreate its state.

Pattern 3: Kafka for Multi-Campus Risk Aggregation

Global banks operating across multiple data centres need consolidated risk views in near real-time. Kafka geo-replication connects campus-level Kafka clusters:

1

[Campus A] Kafka → Geo-Replication → [Campus B] Kafka → Risk Engine

Each campus runs its own Kafka cluster. Geo-replication streams risk events between campuses. The central risk engine consumes from all campuses to compute aggregate exposure.

What You Can Actually Use Today

All three are open source or have open-source editions. Chronicle Queue’s enterprise edition adds encryption and replication.

FAQ

Can I replace Kafka with Aeron? No. They serve different purposes. Aeron is for microsecond latency at the cost of durability. Kafka provides persistence, replayability, and multi-consumer distribution that Aeron does not support natively.

Does Aeron support exactly-once delivery? No. Aeron guarantees best-effort delivery with NAK-based recovery. For exactly-once semantics, you need Kafka transactions or a custom deduplication layer at the application level.

Is Chronicle Queue suitable for multi-process communication? Yes, but with caveats. Chronicle Queue files are designed for same-host access. For cross-machine messaging, you need Chronicle Network or a separate transport layer like Aeron.

Which is the easiest to operate? Kafka requires the most operational maturity — ZooKeeper or KRaft, brokers, replicas, monitoring, and careful tuning. Aeron is simpler (a single Media Driver per host) but requires network expertise. Chronicle Queue is the simplest of the three — a single Java library with no external dependencies.

Further Reading

• Aeron GitHub repository and documentation
• Apache Kafka documentation
• Chronicle Queue GitHub repository

If you are evaluating trading infrastructure, see our Trading & Market Systems Engineering services page. For a broader comparison of messaging technologies, see the Aeron alternatives analysis on our partner site: Aeron Alternatives Comparison.