Designing L2 and L3 Orderbook (without Templates)
with Mechanical and Situational Empathy
Hello folks, it’s been awhile. I’ve spent the last 2+ weeks working day-day on the quantpylib library. A handful of folks have requested access recently, and I have not yet updated the docs, simply because our dev speed is too rapid atm and it would be futile to keep it updated. Forgive me for that.
Previously, we introduced a new state of the art logging subsystem:
And as of late, we have completely revamped the archival subsystem (to a custom L0 binary capture), and am in the process of rewriting the native orderbooks, as well as data replay systems. I am also working on a sidecar terminal application so that traders/market makers with strategies powered by quantpylib have institutional grade trading infrastructure backing them.
Anyhow, since I was on the topic, today, we are going to do a light(er) article on implementing an orderbook. Previously, we already spoke on this topic:
While that was a pretty simple and intuitive discussion, much more detail can be assigned to this task. It is also a common question at quant dev interviews, and I have recently had quant friends drilled on these.
Extending from our previous discussion, if we would like to extend an orderbook implementation into something matching-engine compatible and full-depth, the book needs to support queue position. That means the interface is no longer only MBP (market by price), but rather an MBO surface (market by order).
When it comes to L3 implementation, there are roughly two schools of thought. The standard text of reference is David Gross’s CppCon talk, When Nanoseconds Matter: Ultrafast Trading Systems in C++.
Some of the design pressures in this post are motivated by that discussion. Here we will provide some clarity and implementation on Gross’s solution and also expand on the crypto’s common L2 domain, and how we can support both interface efficiently without template overhead.