hardware - Limit order book size

I am trying to write a highly optimised limit order book and I wondered what sort of size I can expect for:

• Range of limit prices


• Number of orders at each limit price

I am developing custom hardware (FPGA) and thus have very limited amounts of memory available and very different data structures. (The typical pointer-based data structure is normally quite inefficient in an FPGA).

The application is an equities HF market-making strategy in which I require the current top of book from an ITCH data feed to decide inside prices.

Answer

A correct answer would depend on the instruments and markets you're trading, and whether this is for handling public or propietary orders. For example, if I were to design for the simple case, US equities and a public market, I'd want the queue size at each price level to be able to handle at least the maximum daily volume of, say, QQQ. I know that's in no way "highly optimized", but the worst time for your shiny fast book to have a meltdown is when something unexpected has happened somewhere. Likewise for price ranges -- you need to be able to support prices that are at least several orders of magnitude higher than the highest price ever printed in that market. Again taking equities as an example, some of the highly leveraged inverse ETFs have the potential to do things we've never seen before.

If you're dealing in currency pairs, for example, there are way too many ways that a series of political events can blow up your code if you try to make data structures too tight. Use Hungary or Zimbabwe as your model when you're thinking this through; it's possible that squaring the total current value of a given country's money supply might not be a big enough number for a currency pair's future numerator or denominator.

Maybe the real correct answer is the one you probably don't want: Optimize your data structures for speed by using the right algorithms, but don't try to optimize them for size if you want your code to survive interesting times. You might even want to use the maximum size your platform comfortably allows; if you're trading anything that might be subject to hyperinflation, even 64 bits might not be enough for a price field.

It also comes down to the business model that you're planning on supporting; at some point the business needs to know where these limits are and when they might need to exit certain markets before their own systems fail catastrophically.

Another way of approaching this would be to look at the data sizes of the applications which talk to the order book. If you plan on supporting smaller data sizes than those client apps, then you'll want to guard against what will happen when a larger-than-expected value does arrive. The worst case might not be a core dump -- it might be a large order filled at a price that overflowed and wrapped. ;-)