Aeron Q&A – Highlights from NY & London 2025

At our recent Aeron MeetUps in New York and London, we hosted Q&A sessions to foster collaboration and community engagement. Our Aeron engineers, as well as Todd Montgomery, co-creator of Aeron, addressed a multitude of questions from the community about Aeron and trading system design.

The sessions featured pre-submitted questions as well as live queries, providing valuable insights into the technology and its applications. Below are some of the highlights and key questions asked. For the detailed responses, we encourage you to watch the full recording of the Q&A session.

Aeron Q&A: Pre-submitted questions (New York)

1. Why does the publication log buffer use three terms instead of a single ring buffer?
• The decision to use three terms was made after experimenting with one and two terms, which proved to be complex and inefficient. Three terms offered a simpler logic and a good tradeoff between algorithm complexity and memory usage. It enables a wait-free, multi-producer algorithm, avoiding the concurrency issues and unpredictability of a simple ring buffer.
2. How should slow consumers be managed at both the driver and application levels?
• At the media driver level, flow control strategies like max/min/tagged can be used to control the speed at which senders transmit data to receivers. A combination of flow control and tethering can ensure that slow consumers do not affect the overall system performance.
3. How is the Aeron open-source roadmap shaping up. How do you think about what goes into Aeron Premium, what is part of Adaptive’s products and what is open-source?
• Adaptive is fully committed to open source, with nearly all of our products and our services based on the open-source foundation. We continue to invest in and improve Aeron which is visible by the amount of change happening in each software release. Development in the open-source tech is supported by premium subscriptions, which help us fund these efforts.
• The community can also sponsor improvements to the open-source project and we are currently developing a number of features in this way such as ReplayMerge v2 and SBE enhancements.

Aeron Q&A: Pre-submitted questions (London)

1. Does Aeron Cluster support asynchronous snapshotting?
• Yes, with Aeron Cluster Standby [a premium feature], snapshots can be taken asynchronously, offloading the work from the main business logic thread.
2. As Kafka uses ZeroCopy and RocksDB mechanisms to support its functionality, what kind of internal mechanisms are used in the Aeron Framework?
• Aeron is designed around zero-copy and single-write principles to maximize throughput and minimize latency. Data is written once into direct (off-heap) buffers and passed through the system using memory pointers, avoiding unnecessary data copying at every stage—from publication to network transmission and disk storage. Aeron also avoids third-party dependencies, giving it tight control over performance-critical paths. In contrast, Kafka’s architecture relies on a copy-on-write mechanism and leverages RocksDB for log storage, which can introduce additional data copies and more complex layering, potentially increasing latency and reducing predictability compared to Aeron’s streamlined, low-overhead approach.
3. Could you please expand on “post-trade” data persistence and analytics (e.g. kdb) – any advice on architecture to avoid storing the same data multiple times?
• A recommended pattern is to consolidate all relevant data onto a single, indexable stream—using either Aeron Archive or a sequencer with a unique position or sequence number. When writing to downstream systems (such as databases, KDB, or Kafka), then store this logical ID alongside the data. This enables exactly-once processing: if the integration fails and restarts, you can query the downstream system for the last processed ID and resume from that point in the Aeron stream, avoiding duplicate storage and ensuring efficient, reliable recovery.

Aeron Q&A: Live Questions asked in New York and London

1. What are the impacts of clustering on latency?
• Clustering introduces some latency due to the consensus process, but Aeron has optimized its approach to minimize this. Improvements in the layers below Aeron i.e. in the infrastructure, particularly in cloud environments, can significantly reduce latency further. Over the last 5 years we have seen orders of magnitude improvements in this space.
• There are some limitations regarding how fast RAFT can go, 1.5 roundtrips on a network to be explicit. After that, limitations are largely down to physics.
2. Are there plans to provide a C cluster client?
• Aeron currently supports Java and has a C Media Driver
• While there are no immediate plans for a C cluster client, there is increasing interest in supporting multiple languages such as C, C#, RUST, Go etc.
• Adaptive is open to sponsorships and partnerships to accelerate the polyglot nature of Aeron, so interested parties are encouraged to engage with the Aeron team.
3. What are the benefits of using Java for Aeron, and are there any plans to support other languages?
• Java was chosen for its ability to iterate quickly and demonstrate performance. While there are native drivers in C for specific use cases, Java remains a strong choice due to its extensive debugging tools and overall efficiency.
4. What is the status of Rust client bindings for Aeron, and what threading models do you recommend for Rust applications?
• Aeron’s preferred approach is to build non-blocking, single-threaded, agent-based applications for predictability and low latency. For Rust, it’s recommended to use the C API as a base for client bindings, and to avoid blocking operations—regardless of whether you use async runtimes like Tokio or other threading models.
5. We observe latency spikes when publishing or receiving admin action messages in Aeron. How can we reduce or eliminate these spikes?
• Latency spikes can be influenced by buffer sizing, the number of concurrent writers, and the configuration of admin actions. Tuning these parameters and ensuring exclusive publications can help, but a detailed review of your specific setup may be needed to fully diagnose and resolve the issue. Reach out to discuss: info@aeron.io or contact us.

The Q&A session provided valuable insights into Aeron’s design decisions and future plans. The Aeron team remains committed to open source and continues to explore ways to enhance the technology. For a deeper dive into the answers and more detailed discussions, we recommend watching the full recording of the session.