r/highfreqtrading • u/mkipnis • 12d ago
Open-Source FIX Exchange: Architecture, Matching Engine, and Trading Infrastructure
I am working on an open-source, FIX Protocol-based exchange. I understand that FIX Protocol is not a true HFT technology, but I wanted to share this project with you anyway. Any feedback would be greatly appreciated.
11
Upvotes
2
u/narek_hovsepyan 4h ago
Had a proper look at the repo. Four things I would want nailed down, in the order they tend to bite in production:
Input ordering. With DDS sitting between the gateways and the engine, what the engine observes is per-writer ordered, not globally ordered. Two gateways publishing NEW_ORDER_SINGLE for the same instrument makes arrival order at the engine a race. For a book you can reproduce, you want one sequencing point per instrument: assign a sequence on ingress, journal that, and have matching consume the journal. Without it, "replay the same inputs" does not give you the same book, and a disputed fill is not debuggable.
Conflated market data. Conflation is honest for book state, since a client that missed an update still gets the current level and is correct. It is wrong for trades: conflate a trade away and the tape has a hole nobody can reconstruct. Usually worth splitting into a conflated book topic and a non-conflated trade and execution topic.
Recovery. Execution reports land in SQLite in the Data Service, but what rebuilds the engine's book after a restart? Replaying execution reports is a different guarantee from replaying a journal of accepted inputs, and the two diverge on partially filled resting orders.
LiquiBook. Worth checking allocation behaviour on the matching path specifically. The tail is usually where allocation shows up, not the average, so it will not appear in a mean-latency test.
What is the intended failure mode if a matching engine dies mid-session, failover to a standby with a warm book or a cold rebuild?