Aeron: a messaging transport with no broker in the middle

A transport, not a message broker

The README's first line is the whole pitch: efficient reliable UDP unicast, UDP multicast and IPC message transport. Notice what is missing. There is no broker, no topic registry, no consumer group rebalance and no delivery guarantee expressed in the usual at-least-once language. Aeron moves bytes from a publication to one or many subscriptions, and the reliability comes from retransmission logic and a term and position model rather than from a durable log sitting between the two ends.

That single design decision explains both its reputation and its limits. Latency is a property of the wire and the media driver, not of a queue depth somewhere in the middle, and a subscriber can join a stream already in flight by specifying a term and offset. In exchange you are responsible for knowing how Aeron expresses loss, and for handling reconnection after a subscriber goes away. Compare that with Kafka or ActiveMQ, where durability and replay are the broker's problem and the client is simple. Aeron asks for that knowledge back.

It is worth being blunt about discoverability. Anyone searching for `aeron` in a general search engine finds an office chair, and every related phrase the search results carry is about the chair, its price, its headrest or a character of that name. Finding this project means searching for Aeron Cluster or Aeron Archive instead.

What the module layout tells you about the design

The top-level tree is the clearest statement of intent in the repository. `aeron-client/` is the API surface used by applications, `aeron-driver/` is the media driver that owns the transport and the retransmit buffers, and `aeron-all/` is the aggregate artifact most people depend on. Alongside them sit `aeron-annotations/`, `aeron-samples/` for worked examples, `aeron-system-tests/` for the end to end suite, and `aeron-test-support/`.

Two build systems coexist and that is not an accident. `build.gradle`, `gradlew` and `gradle.properties` drive the Java side, while `CMakeLists.txt`, `cppbuild/` and `aeron-config.cmake.in` build the C and C++ clients. Java, C and C++ clients live in this repository; the .NET client is maintained separately by Adaptive Consulting and lives in its own tree. If your stack is .NET you are reading someone else's port, which is worth knowing before you commit.

`version.txt` and `CHANGELOG.adoc` are in the tree, and the README points at the changelog for the current version. That combination is a good sign for a project where a version mismatch between client and driver is the kind of bug that eats a day.

Aeron Cluster as a replicated state machine

Raw Aeron gives you a fast pipe, which on its own is not a service. `aeron-cluster/` is where the project turns that pipe into something that survives a machine losing power, and the mechanism is named in the README: fault-tolerant services built as replicated state machines on the Raft consensus algorithm.

The shape is conventional once you know it. A Raft leader accepts client requests, replicates the resulting state machine commands to followers, and Aeron Archive persists the log so a new leader can replay from the last agreed point. Aeron's contribution is making that log cheap, since the Archive module writes recordings that double as the consensus log rather than shipping messages twice. Aeron Cluster also supplies a session and command protocol on top, so a client can make a request and get a response without hand-rolling message ids.

What the repository does not do is hide the consensus. There is a Design Overview, a Design Principles page and a Flow and Congestion Control document in the wiki, and they are the real entry point. Aeron Cluster is not a drop-in replacement for a database, and a team that adopts it is taking on deterministic replay as an architectural constraint from the first line of code.

Recording streams with aeron-archive

`aeron-archive/` covers the middle ground between a live stream and permanent storage. A recording captures a publication into files on disk, tagged with a recording id, so you can replay it later or later still, and the README is explicit that the same module supports both. Aeron Cluster then sits on top of that, using recordings as its durable log.

Recording also changes how you think about consumers. Because a stream can be replayed from a term and offset, a consumer that was down for a minute can catch up rather than declare a gap. That property is the reason Aeron shows up in systems that need replay semantics, such as a market data feed a client can catch up on, or a telemetry pipeline where losing a minute of samples is unacceptable.

The trade is that you own the retention story. Recordings are files with segments and a catalog, and the wiki's Aeron Archive page is where rotation, local recording and remote recording through an S3 adapter are described. None of that is automated for you out of the box, and archive storage is a real operational surface rather than a managed service.

Open source core, commercial performance features

Ownership is stated plainly in the README. Aeron is owned and operated by Adaptive Financial Consulting, the copyright line reads Real Logic Limited, and the project was originally created by Martin Thompson and Todd Montgomery before the team joined Adaptive in 2022. That history explains the design priorities and the client list: this is infrastructure from people who build trading systems.

The README then lists what Aeron Premium adds, and it is worth reading that list as a map of what the open source version leaves on the table. Kernel bypass with DPDK is a proprietary enhancement, so beating the kernel's network stack is not something the Apache-2.0 code does. So is the encryption path the README calls blazing fast, built on ATS. Training, consulting and help designing a system are commercial as well. Nothing about that arrangement is hidden, but it does mean the headline performance goal in the README, the highest throughput with the lowest and most predictable latency, is a goal the open repository reaches only with the operating system's network stack in the way.

Release rhythm and where Aeron fits against a broker

The project moves often. Version 1.53.2 was published on 2026-09-18, 1.53.1 a week earlier on 2026-09-11, and 1.50.5 on 2026-09-02, with the last push on 2026-09-21 against 8,884 stars and 19 open issues. A small issue count on a codebase this size is consistent with a project that has a clear user base and a maintainer group rather than a wide contributor surface.

Against a conventional broker the difference in approach is exact. Kafka persists every message to replicated logs and gives you offsets, retention policies and consumer groups, at the cost of a round trip through disk and the partitions you have to plan. Aeron lets the producer push at line rate and lets each subscription track its own position, which is why it wins on latency and loses on everything about operational simplicity. RabbitMQ and NATS give you a broker without the throughput story, and for most service to service traffic they are the more honest starting point.

Where Aeron is hard to replace is a many-consumer, one-producer stream where each consumer needs its own view of a fast-moving sequence and every millisecond is on a dashboard. In that shape, with the media driver tuned and the media driver parameters understood, nothing else in the open source world is in the same category.

Editorial conclusion

Aeron is worth the learning curve when your problem has a fan-out shape, many consumers reading the same stream at their own pace, and latency you can see in a profile. That is the trading, market data and telemetry case its own authors came from. It is the wrong shape for request and response between services, where a broker with topics, acknowledgements and rebalancing will save you months. The repository is settled, well documented and versioned frequently, with 1.53.2 published on 2026-09-18 and the last push on 2026-09-21, but it also tells you plainly which parts are commercial: kernel bypass with DPDK and encryption with ATS live in Aeron Premium, not here. Start with the Java Programming Guide and the Transport Protocol Specification, then read Design Principles before writing a single subscription, because Aeron will not stop you from designing the stream wrong.

Frequently asked questions

Official sources

1. aeron-io/aeron on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases