Work
Individual ProjectMarket Microstructure · Execution · SystemsIn development

Limit Order Book Trading Engine

Orders meet by price first and arrival time second. A guided replay shows exactly how full fills, partial fills and remaining orders change the book.

Central findingThe current work-in-progress engine preserves FIFO matching across all deterministic checks and processes approximately 700,000 events per second in documented optimised core-matching synthetic benchmarks.

Evidence

The result in context

Deterministic checks
14 / 14
Events per second
~700k
100k- and 1m-event synthetic benchmarks.
Price-time matching priority
FIFO

Question

Can exchange-style matching mechanics be implemented deterministically, explained clearly and measured under larger event streams?

A deterministic price-time-priority matching engine with replay, execution algorithms, transaction-cost analysis and throughput benchmarks.

The ladder exposes the state the matching engine operates on: price decides the level and arrival time decides queue priority.

Mechanics

Price decides eligibility; time decides priority

The order book maintains bid and ask queues. When an incoming order crosses the spread, it trades against the best available price and then the oldest order at that price.

Partial fills leave a residual quantity either on the incoming order or resting order. The guided replay is a deterministic teaching sequence, not a live market feed.

Guided replay of matching-engine mechanics

Price first. Time second.

This deterministic sequence explains FIFO matching; it is not a live market.

Step 1 of 6

01

Resting book

Older orders sit ahead of newer orders at the same price.

Bids

B180100.00
B212099.00

Asks

A1100101.00
A260101.00
A390102.00

Event tape

Waiting for event

Recorded-style synthetic events can be replayed deterministically to inspect fills, residual orders and state transitions.

Execution

Matching is connected to implementation cost

TWAP, VWAP and participation-based execution can be replayed against market events, with slippage and transaction-cost analysis separating arrival price from realised fills.

Interactive evidence

Optimised core matching sustains roughly 0.7m events per second

Committed project-environment benchmark; timings are machine-dependent.

Read: Throughput is 721,152 events/s at 100k events and 692,787 events/s at 1m, with p95 latency of 2.7–2.9µs.

Data table · 2 verified rows
Complete dataset
Event CountEvents Per SecondP95 Latency UsTradesWorkload
100,000721,151.5925552.786,118100,000 Events
1,000,000692,786.663692.9868,1011,000,000 Events

Validation

Determinism before throughput

Fourteen deterministic checks cover queue ordering, full and partial fills and state transitions. Only after those invariants hold does the benchmark test 100,000- and 1,000,000-event streams.

The measured result is approximately 700,000 events per second for optimized core matching in the documented synthetic benchmark, not a claim about exchange production capacity or full-system throughput.

Limitations

What this evidence does not establish

  • The replay and throughput tests use synthetic or recorded-style events rather than a live exchange connection.
  • Exchange-specific order types, distributed sequencing and production fault tolerance are outside this implementation.
  • The current public repository explicitly labels the engine work in progress.

Source and reproducibility

Trace the evidence

Source code, evaluation outputs and supporting material are available in the repository.

View repository
  1. Order book ladderdocs/images/order_book_ladder.pngCommit / evidence ID: 5413000605359732664ed9672daf0d40f30c64ed
  2. Performance benchmarkreports/benchmark_results.csvCommit / evidence ID: 5413000605359732664ed9672daf0d40f30c64ed