v0.4.0-beta · exchange infrastructure to build on

Benchmarks

The numbers we publish, measured with full Raft consensus on all three nodes, plus exactly what they mean and how to reproduce them. No marketing math.

The headline numbers

From the 2026-07-02 baseline, final verified runs (all 3 nodes live and committing):

Configuration	Sustained rate	Success	Ingress p50	Ingress p99
prod drivers + OS tuning	800,000 orders/s	100.00%	0.22 µs	0.32 µs
prod drivers + OS tuning	700,000 orders/s	99.83%	0.22 µs	2.1 µs
prod drivers + OS tuning	500,000 orders/s	99.23%	0.23 µs	0.34 µs
dev drivers (backoff)	~148,000 orders/s	100.00%	0.26 µs	~1.3 µs

Measured on a single Intel 13700K running a 3-node Aeron Raft cluster with external media drivers, pinned cores, and OS tuning, in local development.

Every accepted order runs the full path: decode, Raft replication to three nodes, deterministic matching in the array-backed book, and egress publication. Zero egress drops and zero consensus failures across all runs.

What the numbers mean (and don't)

Read this before quoting the latency

The p50/p99 above is ingress latency: from enqueue to the cluster accepting the order. It is not end-to-end order-ack latency, which is dominated by a deliberate 20 ms egress batch (a throughput-for-latency trade we chose and can tune). The engine itself matches in about 0.3 µs median. When someone quotes you a sub-microsecond "exchange latency" with no qualifier, ask them this same question.

Success means the cluster accepted the order. The sub-100% entries are brief, client-visible backpressure bursts (retryable, correlated with archive segment rolls), not lost orders. An accepted order is never silently dropped.
The driver profile is decisive: the same code does ~148k/s on polite dev settings and 800k/s on busy-spin prod drivers. Compare configurations, not adjectives.

Where it bends

Pushed to a 1,000,000 orders/s target, the cluster accepts about 90% with bursts near 970k accepted. The clean-at-100% envelope ends between 500k and 600k on this rig; above that, sub-percent backpressure blips appear while the cluster keeps running. We publish the knee because a system's behavior past its rating is the part you'll meet in production.

The environment

Intel i7-13700K (8P+8E), 32 GB RAM, archives on tmpfs, Linux 6.17
Zulu Java 21, generational ZGC, 2 GB heap per node
Aeron 1.51.0, 3-node cluster over loopback UDP, external media driver per node
Load generator pinned to spare cores so it can't flatter the cluster

Reproduce it yourself

From a running stack (see the quick start):

shell

cd match
sudo make tune-persist        # one-time OS tuning
./run-load-test.sh stress     # or progressive / endurance ladders

The full baseline document, with raw interval logs, parsed JSON, per-rung verification, and the methodology caveats, is in the match repo: docs/perf/2026-07-02-performance-baseline.md.