Limit Order Book Queries, Depth, and Consistent Snapshots
Summary
The discussion outlines a minimal query interface for a limit order book used by trading models. In addition to operations that add, cancel, and execute orders, it recommends querying bid and offer depth, then retrieving the price and quantity at a requested level. Level zero denotes the best bid or offer, allowing a strategy to inspect the inside market and deeper levels through the same interface.
The proposed design assumes that order book updates and strategy calculations run in the same thread. With background or asynchronous updates, the answer recommends obtaining a synchronized snapshot and querying that stable copy instead. The snapshot should carry its acquisition time so downstream logic can tell when the displayed quotes were available. This is practical API design guidance rather than a comparison of implementations; it does not specify update protocols, snapshot costs, or behavior under feed delays.
Key ideas
- A basic order book interface can expose depth and price and quantity by level for both sides.
- Level zero can represent the best bid or offer.
- Reading a live book is straightforward when updates and strategy calculations share a thread.
- Asynchronous updates call for a synchronized snapshot to avoid inconsistent reads.
- A snapshot should include its acquisition time to preserve quote timing context.
Tags
Full text
# A generic limit order book: What are the most important queries it should be able to answer? # A generic limit order book: What are the most important queries it should be able to answer? Assume a class `LimitOrderBook` which represents a limit order book in a trading system. To be able to represent the limit order book a data handler reads a feed which adds data to the representation of the limit order book using the following three methods: - `public OrderReference add(Order order)` - `public boolean cancel(OrderReference orderReference)` - `public void execute(...)` These three methods alter the state of the limit order book. These three are more or less given, they're all needed to implement the LOB representation. In addition to those three required "state altering" methods a typical LOB representation also provides a number of query methods that the trading models can call. One obvious example of such a method would be `getBestBid(...)`. What are the most important query methods a general LOB should provide? Or more specifically, in the LOB's you've built, what query methods did you include? Why? ## Answer by wburzyns (score 6, accepted) https://quant.stackexchange.com/a/1225 There is no need to complicate things: ``` ... d = getBdepth(); d = getOdepth(); // for the calls below pos == 0 means the best bid/offer p = getB(int pos); // bid price at pos p = getO(int pos); // offer price at pos q = getBq(int pos); // bid quantity at pos q = getOq(int pos);// offer quantity at pos ``` Note that the above API is not the best choice if your LimitOrderBook instance is updated in background. But as long as you update its state within the same thread that does strategy calculations you're safe. In case of asynchronous updates things complicate a bit - you'll need two classes. The first one will have all the methods you describe plus one for getting a static snapshot of the order book at current time: ``` ... public LimitOrderBookSnapshot getSnapshot(); ``` The LimitOrderBookSnapshot instance is made by synchronously copying data that underlie your LimitOrderBook instance. LimitOrderBookSnapshot API is made of the six calls I described at the top of this post. Also note that in real solution you need to remember the time of getting a snapshot - if you won't you may end up using quotes that were not available at the moment of obtaining the order book data.
Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.