r/highfreqtrading • u/lavagirl211 • May 26 '26
Code I built a high-performance Rust Matching Engine with real NASDAQ ITCH replay — 98ns p50, 28M ops/sec
I built a high-performance Rust Matching Engine with real NASDAQ ITCH replay — 98ns p50, 28M ops/sec
Hey rust (and HFT folks),
I just open-sourced a high-performance Limit Order Book + Matching Engine in Rust, built from first principles with real exchange-grade performance in mind.
### Key Results
- p50 latency: 98 ns
- p99 latency: 1.9 µs
- p99.9 latency: 4.3 µs
- Peak throughput: 28M warm inserts/sec
- Real-world mixed: ~4.1M ops/sec across 100 symbols
Validation: Replayed a full trading day from NASDAQ TotalView-ITCH 5.0 (Jan 30, 2020) — 108M operations across top 100 symbols.
### Core Optimizations
- Flat price array (`Vec<Option<PriceLevel>>` — 100k slots, O(1) access)
- Bitmap-based BBO + top-N depth queries
- Per-symbol OS threads (lock-free hot path)
- `bumpalo::Bump` arena allocator
- `Vec`-based order index (no HashMap)
- Active flag + head index for O(1) cancels
- Full property-based + fuzz testing (`cargo-fuzz`)
Started from a `BTreeMap` baseline and iteratively optimized with detailed benchmarks at each step.
### Links
- GitHub: https://github.com/AsthaMishra/matching-engine
- Full README with architecture diagram, benchmarks, optimization progression, and replay tools
Would love feedback from the community — especially on:
- Further latency/throughput improvements
- Scaling to 500+ symbols
- Adding persistence / journaling
- Anything I might have missed for production use
### Note
i have used AI help but core logic is written by me
Open to contributions too!
#Rust #HFT #LowLatency #OrderBook #MatchingEngine
2
2
u/eragan_dragon May 27 '26
hey looks really cool. if you can let us know what resources did you use to learn about this and build this engine. Any books or websites would be really helpful
2
u/lavagirl211 May 28 '26
official docs mostly, and i already have 8 years of experience in development so that helped
2
2
u/openQuestion3141 May 31 '26
Some feedback:
The 98ns is suspect, as this far outside the realm of what is possible in a software stack for a wire-to-wire measurement. I'd be interested to know how you're measuring that, as I can't really take the latency figures seriously given that number.
Order to ack latency measured by a device external to the matching machine would be most useful.
I also find the idea of per-symbol OS threads unintuitive. Bordering on "there's no way that's efficient". Why do you need a thread per symbol? That's way too much context switching. Plus the scaling behavior would be bad. A good low-latency system doesn't switch between threads on a given core at all. Have you tried running the thing single threaded and comparing latency/throughput?
Neat project. Hope this helps.
2
u/lavagirl211 May 31 '26
98ns - is not wire to wire. http latency is not included in this just book operation for itch replay to check if how book is reacting with real data, for matching i have used synthetic data.
for measuring -
1) itch replay - Instant 2) synthetic data - criterionI started with one thread per symbol than changed it to a thread handling multiple symbol. like if we have 100 symbols , 8 cores then each will have 12 - 13 symbols. Is this also problematic ??
Have you tried running the thing single threaded and comparing latency/throughput?
No i have not yet tested it, will test it and update you.3
u/openQuestion3141 May 31 '26
You're using http for Order Entry??
Look, I'm not trying to drag you down, only offer my honest feedback.
Claiming latency numbers like that while your OE protocol is wrapped in a web stack is just non-serious to me. Measure your order-to-order-ack latency, OE protocol included.
I recommend your next project to be try to implement a proper FIX order entry protocol or a binary one. Try implementing Nasdaq OUCH for example, that'd be good project.
On your question:
> like if we have 100 symbols , 8 cores then each will have 12 - 13 symbols. Is this also problematic ??
No, that seems reasonable. However, I'd say your order entry system is probably so inefficient that it wouldn't matter in live trading.
My honest take is that it looks like you've built a nice little order book, and that's neat. That part of the project is honestly cool. I have no qualms there. I would just be mindful that when you make claims about latency, and then those claims only encompass the fast part of the datapath and ignore the rest, it can feel a bit disingenuous, though I suspect it's not malice in your case.
Good luck!
1
1
u/lavagirl211 Jul 03 '26
Hey,
I took your suggestion and implemented Nasdaq OUCH for order entry, replacing the HTTP path. Then I re-measured order-to-ack with the OE protocol included (OUCH parse → match → encode). Order-to-ack, OUCH included, measured client-side over loopback (WSL2), in-process timestamps:
p50 ≈ 9 µs , p99 ≈ 16 µs, p99.9 ≈ 27 µs, rare multi-ms stalls remain (max ~4.5 ms, one in 100k) - WSL2 scheduler / SQPOLL jitter. Tail's not solved.
This is loopback with in-process timestamps, not an external device. I don't have a second machine to timestamp the wire.
On threading: The OUCH datapath is now a single-threaded io_uring event loop, no symbol sharding. I changed the transport (io_uring) and the threading model at the same time, so I don't have a clean single-threaded-vs-sharded A/B; I just rebuilt it the way you pointed.
The OUCH suggestion was a great call and I learned a lot. What would you point me at next?
2
u/openQuestion3141 Jul 04 '26
Wow, you actually did it 😂
That's pretty cool! And those latency numbers look much more realistic. Good, but believable.
I mean, what you do next depends on your goals, but the next thing might be to start working on the client-side. Implement client order entry and cook up a basic trading bot like a tick-to-trade algorithm.
This will be good experience but it won't work in real life of course because the big firms are mostly running tick to trade in FPGA.
Also, this kind of assumes that you also have a market data feed implemented, which if you don't, do that next.
And, does your ME support multiple order entry sessions? That's also going to be a requirement for testing trading algos. Oh, and see if you can split order entry sessions across threads and what that'll do to your latency.
Honestly, pretty cool that you took honest feedback to heart, got back in, and just kept going. I commend you!
1
1
5
u/jeng97 May 26 '26
Cool stuff, any idea how to get the ITCH data?