The matching engine is the smallest part of an exchange and the only one that cannot be slightly wrong.
Everything else — the wallet, the onboarding pipeline, the admin console — can degrade gracefully. A matching engine that misprices a fill or drops an order under load does damage that is visible, public and hard to explain.
What it has to do
Ingest orders. Maintain the book. Match bids against asks by price-time priority. Emit trades. That is the whole job description and it is deceptively small.
The difficulty is entirely in the constraints around it: it must be fast, it must be exactly correct, it must behave identically every time, and it must not fall over when volume arrives faster than anyone planned for.
Single-threaded per market, deliberately
The instinct is to parallelise. For a matching engine it is the wrong instinct.
A single thread per market, processing a strictly ordered input sequence, gives you something much more valuable than concurrency: determinism. The same inputs always produce the same outputs, in the same order.
Parallelism goes elsewhere — different markets on different threads, and everything upstream and downstream scaled horizontally. The core matching loop stays boring.
Language choice
Rust for latency, Go for throughput and developer velocity.
The real criterion is predictability. Garbage-collected runtimes introduce pauses that are fine in a web service and unacceptable here, because a pause during a volatile minute is when it matters most. A consistently slower engine beats an intermittently unpredictable one.
Designing for the spike, not the average
This is where most in-house engines fail, and the failure mode is consistent.
An engine built by a small team handles daily volume comfortably for a year. Then a listing event pushes order flow to many multiples of baseline within seconds, the engine falls over mid-session, open orders cancel, and support cannot answer fast enough.
The fix is unglamorous: load-test against synthetic traffic modelled on your own spike patterns. Not a generic benchmark. Your own historical bursts, amplified, replayed against the engine until it breaks — then find out where.
We rebuilt exactly this for a multi-asset retail exchange whose original engine had been written early by a very small team. The rebuild went into the next comparable listing event with headroom rather than hope.
Deterministic replay
Record the input sequence. Feed it back. Get identical output.
This buys three things that are individually worth the effort:
- Dispute resolution. A trader questions a fill; you reconstruct the book at that exact moment rather than arguing.
- Incident debugging. Replay the minutes before a failure as many times as you need.
- Safe migration. Run a new engine against recorded production traffic and diff the output before it touches a live order.
Without replay, an engine rewrite is a leap of faith. With it, it is a test.
What sits around it
The engine does not live alone, and scoping it in isolation is a common planning error.
- Risk, checking limits before an order reaches the book.
- Surveillance, watching for wash trading and manipulation patterns in the trade feed.
- Market data, fanning the book out to clients over WebSocket and FIX without slowing the core.
- Settlement, moving balances after a match, reconciled against custody.
Each of these reads from or writes to the engine, and each has to do so without being able to stall it.
The practical sequence
Build the engine first and prove it. Load-test it against your own patterns before anything else is wired in. Add replay from day one rather than retrofitting it, because retrofitting means changing the exact code you least want to touch.
Then build outward — risk, market data, settlement, surveillance — with the engine as the fixed point everything else agrees with.
Common questions
What is a crypto matching engine?
The component that ingests orders, matches bids against asks and emits trades. It maintains the order book, enforces price-time priority, and produces the trade feed everything else depends on. It is the smallest component in a crypto exchange by surface area and the one with the least tolerance for error, because every other system reads from what it produces.
What language should a matching engine be written in?
Rust when latency is the priority, Go when throughput and developer velocity matter more. Both avoid the garbage-collection pauses that make a JVM or Node engine unpredictable under load, and unpredictability is worse than slowness in this component. What matters more than the language is that the engine is single-threaded per market with deterministic ordering, which is what lets you replay and reproduce any session.
How many orders per second does an exchange need to handle?
Far more than your average, because averages are not what break an engine. Design against your worst plausible spike rather than your daily throughput. A listing event can push order flow to many multiples of baseline within seconds, and an engine sized for normal operation fails at exactly the moment the most people are watching. Load-test against synthetic traffic modelled on your own spike patterns, not a generic benchmark.
What is deterministic replay and why does it matter?
The ability to feed the same input sequence into the engine and get byte-identical output every time. It matters because traders dispute fills, and the only satisfying answer is to reconstruct exactly what the book looked like at that microsecond. It is also how you debug production incidents and how you validate an engine rewrite against the old one before switching.
Does Corum8 build matching engines?
Yes. We build them in Rust or Go with deterministic replay, single-threaded-per-market ordering and load testing against your own traffic patterns, plus the risk and surveillance layers that sit alongside. We have built exchange infrastructure since 2016 with 95+ specialists across engineering and marketing.
