Matching Gateway joins binary market-data ingest to a price-time limit order book: market data and client orders go in, trades and acknowledgements come out, with sessions recorded and replayed deterministically.
One Book as the Source of Truth
Applied market-data add, cancel, and modify events are mirrored onto the matching book as resting GTC liquidity, while client orders arrive over a compact wire protocol supporting new, cancel, and modify across GTC, FAK, FOK, GFD, and market types. Both paths settle against a single shared orderbook, so there is exactly one authority on what filled.
Execution Reports
Every client order resolves into an explicit report rather than silence:
Ack - The order was accepted and is now resting in the book.
Trade - The order matched, in whole or in part, against resting liquidity.
Reject - The order was refused, as with a duplicate client order id or a fill-or-kill that cannot be satisfied, leaving the book untouched.
Cancel Ack - A cancel request was applied and the order is gone.
Deterministic Sessions
The gateway records a session and replays it to an identical trade log. Combined with the feed handler's sequence tracking, that makes the entire path reproducible from a file: gap detection, out-of-order buffering, and matching all replay the same way twice.
Measured, Not Claimed
On a modern desktop in a release build, resting client orders process at roughly 1.05M orders/s and aggressive matches against a market-data-seeded book at roughly 0.57M orders/s, with ingress-to-ack latency showing a median near 700 ns and a p99 around 3.4 microseconds.
Those are gateway-internal numbers from an in-memory, single-threaded stack with a map-backed book and pooled orders. They are deliberately not presented as exchange wire-to-book latency, which is a different measurement entirely.
Built on the Feed Handler
Market data arrives through the vendored feed handler from Market Data Feed, and the matcher is the price-time book from Orderbook. This is the layer where those two meet.