I am working on a “Trade Book” type algorithm that needs to be very robust, yet work within the constraints of commodity hardware. Let’s see what we can do with these specs:
- Memory: Somewhere there is an optimal setting for how much of the order book is in memory. Should it all be there? What about orders way outside the best bid/offer?
- Fault tolerance: With commodity hardware and hosted systems, an unexpected failure is a real possibility. While it doesn’t necessarily need to be automatic, there should be something that assures the book can be recreated to its point before the crash (i.e. ACID)
- Fast and Efficient: This should be built with testing in mind. While we want to avoid premature optimization, the tooling should be integrated but get out of the way once the code rolls into production (#DEFINEs?)
- STL vs Boost vs ??: Algorithms around the order book should allow for replacement. While this will slow things down a bit during testing, it should be written in such a way to be easily cleaned once the best (that can be found) algorithm is chosen.
- Threading: The order book should be single threaded (yep, that’s right!). Queueing will be handled outside the algorithm. Wow, a bullet item that will hopefully make things easier!
These are tall orders to be sure. The first orders of business will be around selecting the tooling, testing frameworks, and gathering some metrics.
It’s been ages since I messed with (or even thought about) 2PC logic. Nostalgia and cobwebs.