The World's Fastest Matching Engine Algorithm

Abstract: Every electronic exchange relies on an order book whose storage layer determines matching latency. The dominant implementation -- linked lists chained through a balanced tree -- imposes two costs on every operation: pointer-chased traversal to reach the insertion point, and root-to-leaf search to locate the target price level. Under micro-burst conditions these costs produce tail-latency spikes that degrade market quality when liquidity is most needed. We present two data-structure contributions that eliminate these costs. The first is the Priority-Indicated Node (PIN), a priority queue in which entries occupy fixed-capacity, contiguously addressable slots, each carrying a per-slot indicator encoding the entry's global priority. Unlike heaps, which require O(log n) comparisons per operation, the PIN resolves insertion position directly from the indicators without comparing entries; indicator updates are O(1), independent of queue size. The second addresses a broader inefficiency: balanced search trees search root-to-leaf on every insertion and deletion, even when the caller already knows the key's in-order neighbors -- as in ordered event streams, incremental index already knows the key's in-order neighbors -- as in ordered event streams, incremental index maintenance, and electronic trading. Neighbor-aware insertion and deletion exploit known neighbor references to attach or remove a node with O(1) reference writes, followed by single-path rebalancing, uniformly across red-black, AVL, and B/B+-tree variants. A single CPU core sustains 32 million order messages per second with sub-microsecond tail latency under multi-million message-per-second micro-bursts, and is 5-11x faster than the best available open-source matching engines on the same hardware. Scaled to a single 96-core instance, the engine sustains 640 million messages per second across 10,000 symbols.

• The paper introduces Priority-Indicated Nodes and neighbor-aware balanced-tree updates, achieving 30–33 million messages per second per core with median latency of 49 nanoseconds and P99 latency of 128 nanoseconds.
• The evaluation uses deterministic, byte-identical trade verification and calibrated synthetic workloads, showing 5–11× gains over verified open-source engines and approximately 640 million messages per second across 96 cores.
• The results show that cache locality and serialized per-symbol processing—not aggregate infrastructure throughput—limit matching engines, while FPGA implementation, production-trace validation, and full networking remain open challenges.

Motivation: the per-symbol matching loop as the bottleneck

The paper's central claim is that the dominant bottleneck in modern electronic exchanges is not network latency or aggregate infrastructure throughput, but the strictly serialized, per-symbol matching loop. Because price–time priority requires a single deterministic message sequence per instrument, Amdahl's law caps per-symbol throughput regardless of parallelization elsewhere. Public documentation supports this framing: Deutsche Börse T7 measurements show inbound bursts of ~8 million messages/s at the gateway collapsing to ~300,000 messages/s at matching ingress (2606.01183), and Eurex documentation reports per-partition sustainable throughput in the few-hundred-thousand range. During micro-bursts—sub-millisecond spikes carrying a disproportionate share of daily volume—the serialized core saturates, queues build, and tail latency becomes queuing-dominated rather than compute-dominated.

The economic argument is developed carefully. Congestion-induced execution uncertainty exposes stale quotes to latency arbitrage; Aquilina, Budish, and O'Neill estimate eliminating stale-quote sniping would reduce effective spreads by up to 17% and that sniping extracts roughly $5 billion annually from liquidity providers. In U.S. equities, Regulation NMS Rule 611 amplifies the stakes: a venue that cannot refresh quotes fast enough loses NBBO status and routes marketable flow to competitors. The paper cites TSE's Arrowhead upgrade (effective spreads down 6.45%, marking-the-close manipulation down 61%, trading revenue up 7.7%) as documented evidence that capacity upgrades translate directly into market quality and revenue. These are strong claims, but they are anchored to cited empirical studies rather than asserted.

Data-structure contributions

The architecture rests on two components.

Priority-Indicated Node (PIN). The PIN is a fixed-capacity priority queue node with a contiguously addressable slot region (base-plus-stride addressing, no pointer chasing) and per-slot priority indicators encoding each order's global priority status under price–time ordering. Insertions are expressed as Append/Prepend with constant indicator updates; when a node is full, a directed relocation cascade of bounded depth $D_{\max}$$moves orders toward adjacent nodes before allocating a new boundary node. This avoids both the pointer-chasing of linked lists and the$$O(n)$$suffix-shift of flat arrays on random-position cancels—which matter because ~95$$O(1)$$without scanning.</p> <p><strong>Depth-aware capacity model.</strong> Node capacities vary by depth from top of book via a monotone nonincreasing function$$\kappa(d)$$. Using an empirically grounded model—power-law update intensity across levels ($$\ell^{-\beta}$$), exponentially decaying queue lengths, uniform within-level hit distributions—the paper derives an optimal top-of-book capacity$$k^* = \frac{1}{C_{\text{top}}} \ln\!\left(\frac{t_R C_{\text{top}}}{A}\right)$, balancing L1 miss penalty$t_R$against per-slot scan cost$A$. The derivation is honest about its limits: the exponential queue-length decay fails in the first one to five ticks of liquid equities (&quot;hump&quot; effect), so the analytic $k^*$ is a conservative lower bound there.</p> <p><strong>Neighbor-aware balanced trees.</strong> The second contribution generalizes beyond order books: when a caller already knows a key&#39;s in-order neighbors, insertion/deletion reduces to $O(1)$$reference writes at the unique BST-valid attachment point (exactly one of$$O(n)$0 or $O(n)$1 is null), followed by the standard single-path rebalancing walk. The theorem is stated representation-independently across red-black, AVL, and B/B⁺-tree variants, with scapegoat-style global-rebuild trees excluded. When neighbors are unavailable, the structure falls back to textbook $O(n)$2 descent—a strict improvement rather than a trade-off. The technique applies wherever updates exhibit key-stream locality.

Evaluation

All experiments ran on a dedicated AWS r8g.metal-24xl Graviton4 instance (96 Neoverse-V2 cores, single NUMA node); an x86 build reaches ~70% of reported throughput. Workloads are calibrated to NVIDIA market microstructure: power-law depth exponent $O(n)$3, 95% cancellation rate, 15% IOC share, GBM mid-price dynamics across five volatility scenarios from static through 60% flash-crash swings, with fixed seeds for reproducibility.

Single-core performance. One matcher servicing one symbol sustains 30–32 M msgs/s (~31 ns/order) under normal-trading-day conditions, rising to 33 M/s under static prices. Pre-filling a standing book of ~34K orders across 800 levels degrades throughput only to 25.6 M/s, and a deliberately harsher $O(n)$4 distribution costs ~14%. End-to-end pipeline latency over 301K samples shows median 49 ns, P99 128 ns, P99.9 223 ns, P99.99 365 ns, and a 626 ns interrupt-free maximum. The multi-modal latency histogram maps cleanly onto L1/L2/L3 residency, consistent with the depth-aware capacity model concentrating hot orders in L1.

Multi-symbol scaling. Multiplexing symbols on one core costs substantially: 10 symbols halve throughput to 15.9 M/s, and 10,000 symbols yield 9.89 M/s (69% overhead). The paper attributes this to cache-locality degradation rather than algorithmic work—an important concession that motivates the hardware path. At instance level, 96 cores sustain ~640 M msgs/s across 10,000 symbols under Zipf-distributed flow, exceeding the CTA feed's provisioned 27 M/s capacity by more than 20× on a ~$1,630/month server.

Head-to-head comparisons. All engines were verified byte-identical on trade output against a deterministic stream before any speed comparison—a methodological prerequisite the paper argues is often skipped. Notably, this verification surfaced a genuine correctness defect in Liquibook's IOC handling (a conditions flag written to a local parameter instead of the member), causing uncorrected Liquibook to emit ~4× the consensus trade count; all comparisons use the corrected build.

Baseline	Design	Speedup vs. proposed engine
Liquibook	Tree-of-lists, $O(n)$5 cancel scan	~11×
Exchange-core	Adaptive radix tree + Disruptor	4.7–6.0×
QuantCup 1	Flat array	up to 216× (flash-crash)

QuantCup's collapse—from 5.11 M/s static to 0.15 M/s under 60% swing—is attributed to linear scans through empty price slots under drift, illustrating the paper's thesis that contiguous memory alone is insufficient without priority indicators decoupling logical priority from physical position. Against Exchange-core at instance scale, the apples-to-apples (no-risk) comparison yields 152×; the out-of-box configuration's inline risk processing accounts for a 35× self-degradation, which the paper correctly identifies as unrepresentative of production exchange architectures, where stateful risk checks live upstream (Rule 15c3-5) and at clearing.

Limitations and open questions

Several caveats deserve emphasis. First, the headline results measure the in-process matching pipeline; full networking integration, rich business logic, and stringent regulatory checks are explicitly deferred. Second, the FPGA embodiment—the claimed resolution of the multi-symbol cache-locality ceiling—is described but not yet realized; only CPU results are reported, so the hardware claims remain specifications rather than measurements. Third, the analytic capacity model relies on empirical regularities (power-law intensity, exponential decay) that fail near top of book, requiring online estimation the paper does not detail. Fourth, baseline comparability has boundaries: Liquibook's gap is partly an implementation choice (an order-ID hash map would close much of it, as the authors concede), and Exchange-core lacks out-of-box multi-JVM sharding infrastructure. Finally, the workload generator, while regulator-calibrated, remains synthetic; validation against recorded production message traces is an open question.

Conclusion

This paper reframes matching-engine performance as a data-structure and cache-locality problem and delivers two concrete mechanisms—PINs with priority indicators and neighbor-aware balanced-tree updates—that together yield 30–33 M msgs/s per core with sub-microsecond tails, 5–11× faster than verified open-source baselines, and ~640 M msgs/s per 96-core instance. The evaluation methodology, particularly byte-level correctness verification preceding all throughput comparisons, strengthens the credibility of the head-to-head numbers. The principal unresolved question is whether the specified FPGA realization delivers the flat multi-symbol scaling the CPU results predict it should.