Order Book Reconstruction from Message Feeds

Exchanges don't publish "the order book" as a live snapshot — they publish a stream of discrete messages: a new order was added at this price and size, an existing order was modified or canceled, a trade occurred. To simulate what the book looked like at any given millisecond, or what a resting order's queue position was, a backtest has to apply every one of those messages in the exact order they were sent and maintain the running book state itself. This process — turning a message stream into a live order book — is order book reconstruction, and getting it wrong produces a simulator that's confidently showing the wrong market.

The mechanics: a running ledger, not a lookup

Reconstruction works like replaying a ledger: start from either an initial snapshot or an empty book, then apply each message in sequence — add inserts a new resting order at its price and size; modify changes size (and, depending on the exchange's rules, may reset the order's queue priority); cancel removes an order; a trade message reduces the resting quantity at the price level it executed against and, on exchanges that report full order-level detail (L3), identifies which specific order was hit. Every message must be applied in the sequence number or timestamp the exchange assigned it, because these messages are only meaningful relative to each other — a cancel message means nothing without knowing exactly which prior add it's canceling, and applying messages out of order produces a book state that never actually existed.

Worked example: reconstructing five messages

Starting from an empty book at one price level, the exchange sends:

#	Message	Book at this price after applying
1	Add order A, size 100	100 (A)
2	Add order B, size 50	150 (A, B)
3	Cancel order A	50 (B)
4	Add order C, size 80	130 (B, C)
5	Trade: 50 executes against B	80 (C)

After message 5, the reconstructed book correctly shows only order C resting with size 80 — order A is long gone, order B was fully consumed by the trade, and the queue order matters too: because B arrived before C and wasn't canceled, B had priority and was the one filled by the incoming trade, not C, even though C also had resting size at that price. Getting message 3 processed before message 4, or applying the trade before the cancel, would silently produce a different, wrong book — this is why sequence numbers, not arrival time at the simulator, must drive the reconstruction.

What this means in practice

Reconstruction quality is the ceiling on simulation fidelity for anything that depends on book depth or queue position — a matching engine or fill-probability model is only as good as the reconstructed book it's simulating against. Common failure modes are dropped or out-of-order messages from a lossy feed, misinterpreting a "modify" as preserving queue priority when the exchange's actual rule resets it, and gaps handled by silently skipping rather than flagging — any of which quietly corrupts every downstream simulation result without an obvious error.