AERON LOW-LATENCY MESSAGING: A PRACTICAL GUIDE FOR FINTECH AND TRADING SYSTEMS
Microsecond-level latency isn’t a nice-to-have in financial trading. It’s the difference between filling an order and missing the market.
Most messaging systems were built for throughput, not speed. Kafka processes millions of messages per second, but its architecture adds 2-10 milliseconds of latency that makes it unusable for direct market access or real-time risk calculations. RabbitMQ and NATS don’t come close either.
Aeron was built from the ground up for the sub-millisecond world. It’s the messaging layer behind major exchanges, trading firms, and payment systems.
Who Is This Guide For?
Engineers and architects building latency-sensitive financial systems — trading platforms, market data feeds, real-time risk engines, and payment infrastructure. If you need to move data between processes or machines in under 100 microseconds, this is for you.
By the End of This, You’ll Know
- How Aeron’s architecture achieves sub-20 microsecond latency
- When to use Aeron vs Kafka, ZeroMQ, or Chronicle Queue
- How to deploy Aeron Cluster for fault-tolerant messaging
- Common pitfalls in production Aeron deployments and how to avoid them
What Makes Aeron Different
Aeron is not a message broker. There is no central server, no disk-based persistence by default, no heavyweight protocol parsing. It’s a transport layer that maps directly to UDP multicast or unicast, with a thin reliability layer on top.
The architecture is deceptively simple. Publishers write messages to a claimed buffer in shared memory or direct memory. Subscribers read from that buffer. The Media Driver handles the actual network I/O in a separate thread or process, using busy-spin polling instead of kernel interrupts to minimize latency.
Real Logic — the company behind Aeron — designed it for the Aeron Cluster protocol, which extends the basic transport with Raft-based consensus for state machine replication. Adaptive (weareadaptive.com) now commercializes Aeron through aeron.io, offering a managed cloud service that closes the performance gap between on-premise and cloud trading infrastructure with sub-20 microsecond messaging.
Aeron treats latency as a first-class constraint. Most messaging systems treat it as an afterthought.
Latency Benchmarks: The Numbers That Matter
The Aeron Files (theaeronfiles.com) publishes reference benchmarks under controlled conditions:
| Transport | Median Latency | 99.9th Percentile | Throughput |
|---|---|---|---|
| IPC (same process) | < 1 microsecond | < 5 microseconds | 100M+ msg/s |
| UDP loopback | ~2 microseconds | ~10 microseconds | 10M+ msg/s |
| UDP intra-DC | ~15 microseconds | ~50 microseconds | 5M+ msg/s |
| UDP cloud (same region) | ~50-100 microseconds | ~500 microseconds | 2M+ msg/s |
Compare this to Kafka’s typical 2-10 millisecond P99 latency in cloud deployments, or RabbitMQ’s 100-500 microsecond range for in-memory delivery. Aeron operates in a completely different latency regime.
The tradeoff: Aeron achieves this by sacrificing durability guarantees. Messages exist in memory and on the wire. If a subscriber crashes before processing, the message is gone unless you use Aeron Cluster’s replicated log.
Aeron Cluster: When You Need Both Speed and Safety
Aeron Cluster extends the basic transport with a Raft-based consensus protocol. Multiple nodes (minimum three for production) maintain a replicated log of state machine transitions. This gives you:
- Fault tolerance: If a node fails, the cluster continues
- Exactly-once semantics: The replicated log ensures no message is lost
- Snapshotting: State machines can be snapshotted for fast recovery
The cluster protocol is not a generic Kafka replacement. It’s designed for applications that maintain in-memory state — order books, risk positions, trading engines — and need that state replicated with minimal latency overhead.
Real Logic’s benchmarks show Aeron Cluster adds approximately 50-100 microseconds of latency over base Aeron, still 10-50x faster than Kafka with exactly-once semantics enabled.
Aeron in Production: What Actually Matters
After working with teams deploying Aeron in production environments, several patterns emerge consistently.
Pin the Media Driver to dedicated CPU cores. Aeron uses busy-spin polling, which means it burns CPU cycles waiting for messages. This is intentional — context switching and kernel interrupts add microseconds. Pin the Media Driver thread to isolated cores (use isolcpus on Linux) and configure Aeron’s thread affinity via the aeron.threading.mode property.
Tune your JVM for Aeron. Aeron is written in Java and uses off-heap memory via sun.misc.Unsafe for its buffers. The JVM’s garbage collector must be configured to avoid STW pauses. Use ZGC or Shenandoah with a 10ms max pause target, and pre-touch memory with -XX:+AlwaysPreTouch.
Watch your UDP buffer sizes. Aeron’s UDP transport depends on OS-level socket buffers. The default Linux UDP buffer size (208KB) is far too small for high-throughput Aeron streams. Set net.core.rmem_max and net.core.wmem_max to at least 16MB, and configure net.core.netdev_budget to handle interrupt coalescing.
Never deploy Aeron without monitoring. Aeron exposes rich metrics via its CncFile (counter file) — including send/receive rates, loss reports, and backpressure status. Feed these into a monitoring system. The metric most teams miss is the loss detector — a non-zero loss count in Aeron indicates network congestion or misconfiguration, and it always needs investigation.
Aeron vs Kafka: When to Use Which
The decision isn’t Aeron or Kafka. It’s which layer of your architecture gets which tool.
| Criterion | Aeron | Kafka |
|---|---|---|
| Latency | Sub-20 microseconds | 2-10 milliseconds |
| Persistence | In-memory (replicated via Cluster) | Disk-based, configurable retention |
| Protocol | UDP (multicast/unicast) | TCP with binary protocol |
| Tooling | Minimal (CLI counters) | Rich ecosystem, Kafdrop, Control Center |
| Operational overhead | High (CPU pinning, JVM tuning) | Moderate |
| Best for | Trading, market data, risk engines | Event sourcing, audit logs, analytics |
Aeron handles the latency-critical path — order entry, market data distribution, position keeping. Kafka handles everything else — trade reporting, compliance logging, analytics pipelines.
What You Can Actually Use Today
Start with the Aeron Samples. The Aeron source repository includes working examples for IPC, UDP, and Cluster communication. Run BasicPublisher and BasicSubscriber on your development machine to validate latency expectations before designing your architecture.
Use the aeron.io managed service if you’re deploying in the cloud. Adaptive’s managed Aeron handles Media Driver configuration, cluster orchestration, and monitoring. For on-premise deployments, the open-source Aeron distribution gives you full control but requires careful JVM and kernel tuning.
Pair Aeron with Chronicle Queue for persistent, low-latency logging of trading events. The combination is common in fintech — Aeron for real-time transport, Chronicle Queue for disk-based audit trails that maintain microsecond write latency.
Monitor loss from day one. Deploy a health check that polls Aeron’s loss counter and alerts on any non-zero value. Most production incidents with Aeron start with unexplained packet loss that compounds over time.