Bullish – Leveraging Aeron Sequencer to scale a regulated crypto exchange

At our recent Aeron Community MeetUp in New York, Pierre Falda, Director of Trading Engineering at Bullish, shared how the firm evolved its exchange architecture from a first-generation design that used Aeron mainly at the FIX edge into a second-generation model built around replicated state machines, with Aeron firmly used across the entire core platform. The goal was to improve determinism, resilience, scalability, and latency for a regulated, cloud-native exchange serving institutional customers. Watch the full recording of this session here.

Who is Bullish and what do they do?

Bullish is a regulated crypto exchange that runs in the cloud and is focused on institutional customers. In the presentation, Pierre describes the platform as needing to deliver the same consistency, auditability, and fault-tolerance expectations as traditional regulated exchanges while also competing on latency in always-on crypto markets.

Challenges faced by Bullish in scaling its digital asset exchange

Initially, Bullish’s first-generation platform was built at speed using a combination of custom components, generic middleware, and Aeron, primarily at the edge for FIX ingestion. The architecture was good enough to get the business started and run safely in production, but as Bullish grew, it became clear that the platform would not support the next phase of scale, resilience, and performance they wanted to achieve.

Bullish required a system that was:

• Fully deterministic, so the platform could be replayed from original inputs and issues could be reproduced more cleanly in testing and debugging.
• High-performance, without the latency ceiling and long-tail delays introduced by centralized generic middleware.
• Capable of running 24/7 with strong availability, avoiding failover blips, manual rollover processes, and order drains during recovery or releases.
• Able to scale in the cloud, so that Bullish could shard workloads across engines and services while maintaining a consistent view of exchange state.

Why Bullish chose Aeron for its exchange platform

Aeron, as the infrastructure foundation for Bullish’s next-generation architecture, was chosen for several key reasons:

• Performance: Bullish selected Aeron because it offers best-in-class latency across transport, IPC, and persistence components, making it suitable for the hot path of a low-latency exchange.
• Scalability and high availability: Bullish saw Aeron Sequencer, which brings the robustness of Aeron Cluster to distributed systems, as the basis for total ordering, consensus, and sharding across multiple consumers and machines in a cloud environment.
• Deterministic replay and testability: Aeron Sequencer gives Bullish a stronger foundation for replay, debugging, and building a fully deterministic replicated state machine than its previous middleware-based design.

How Bullish uses Aeron in its current exchange architecture

Bullish uses Aeron as a platform rather than just a messaging library. In its second-generation design, Aeron provides the key infrastructure primitives for ordering, persistence, IPC, and network transport, allowing Bullish to simplify the stack and focus on its business logic.

Bullish’s exchange architecture includes:

• Matching engines: Multiple matching engines can consume from the same sequenced journal, either as redundant active/active instances or partitioned by market group.
• Accounting and risk services: Accounting and risk run as independent consumers of the same ordered stream, giving Bullish a consistent view across engines while allowing those services to scale separately.
• Archive and journal: Bullish uses Aeron Archive as the binary journal for persistence and replay, with downstream consumers also able to tail the archive directly for non-latency-sensitive use cases.
• IPC and media driver: Aeron Transport [IPC] is used for co-located process communication, while the media driver supports network transport and egress patterns across the platform.

The overall design is much more modular than Bullish’s first-generation architecture. By attaching independent consumers to a totally ordered log, Bullish can scale matching, accounting, and risk more flexibly without coupling everything through a single shared middleware bottleneck.

Technical elements and key learnings from Bullish’s Aeron implementation

The technical implementation of Bullish’s exchange platform includes several critical elements that ensure its robustness and efficiency:

• Single-threaded business logic: Bullish keeps engine execution single-threaded after sequencing, which removes locks and races and makes deterministic processing possible.
• Totally ordered input log: A key lesson from Bullish’s first-generation system was that approximate ordering was not enough. In the new design, the sequencer provides a globally ordered log that supports deterministic replay from the sequenced input itself.
• Zero-allocation binary journal: Bullish’s journal is built on Aeron Archive with SBE encoding, following zero-allocation and single-writer principles to reduce jitter and keep the hot path efficient.
• Formal verification: Bullish uses TLA+, TLC, and TLAPS to verify business invariants and reconciliation logic, with formal checks integrated into CI and linked back to code through annotations.

Rapid deployment and performance – Bullish performance figures

In microbenchmarks, Bullish said its Aeron Archive-based logging path achieved around 66 nanoseconds p99 per log entry and sustained 10 to 15 million messages per second per thread, reflecting the efficiency of its zero-allocation binary journal design rather than end-to-end production latency figures.

Architecturally, Bullish also emphasized that the new design enables active/active redundancy, rolling upgrades without draining orders, and failover without the release-time disruption that existed in the earlier platform.

Future plans for Bullish’s exchange platform growth

Bullish plans to continue building on its Aeron-based architecture as it rolls out more of the second-generation model. The talk highlights further use of the sequencer for total ordering across more consumers, broader sharding of matching, accounting, and risk workloads, and continued scaling across machines and market groups.

It also signalled an ongoing focus on formal verification and deterministic replicated-state-machine design as core engineering disciplines, not add-ons, for running a regulated exchange in the cloud.

1. 

   Pierre Falda Director of Trading Engineering
   Bullish

   LinkedIn profile

   Pierre is Director of Trading Engineering at Bullish, a regulated digital asset exchange serving institutions and advanced traders. A Java ultra-low-latency specialist with over 20 years in trading and distributed systems, he previously led trading engineering at Bitvavo and Flow Traders.