Rebuilding an order book from deltas

Exchanges do not send you the book. They send you what changed, and you are expected to hold the rest in memory correctly, for days at a time, without drifting. This is the part that separates a live tool from a chart of yesterday.

Why not just poll an API

Because the useful state of an intraday market is the book, and the book changes faster than any polling interval you would be allowed. Published snapshots arrive late and aggregated; by the time you see one, the order you wanted is gone.

Market participants get a different route: a message queue carrying every change as it happens. In the Czech market that is an AMQP interface authenticated with a client certificate. Other European exchanges expose comparable feeds.

Getting connected

• TLS with a client certificate. Not a token in a header — a real x509 certificate issued to the participant, with the key living somewhere it can be rotated without a redeploy.
• A login and subscribe handshake defined by the exchange, not by the AMQP standard. Get the order wrong and the connection opens, accepts you, and sends nothing.
• Compressed payloads. Ten levels a side across every product produces tens of megabytes a day, so messages arrive gzipped.

Reconstructing the book

Each message is a change: an order added, amended or cancelled. The consumer keeps the book and applies them in order.

1. Track order identifiers. An amendment references the original; losing that mapping means a stale order sits in your book forever.
2. Handle cancels explicitly. The most common bug in home-grown consumers is a cancelled order that never leaves the depth, quietly inflating liquidity.
3. Watch sequence numbers. A gap means you have lost state and the only honest response is to resynchronise, not to carry on.
4. Rebuild on reconnect. After a drop, the book must be discarded and rebuilt rather than patched — the alternative is a book that looks plausible and is wrong.

From a correct book, the useful numbers fall out: best bid and ask, spread, depth at a price, volume-weighted average price, and the spread of intraday against the day-ahead result for the same delivery period.

What it is used for

• Spread screening — where intraday trades away from the day-ahead auction for the same hour or quarter hour.
• Execution context — how much can actually be moved at a price, which a price series alone never tells you.
• Recording. Every message is archived, so the book can be replayed exactly as it was at any past moment. That is what makes honest backtesting possible at all.

Stack and effort

• Python with an AMQP client, TLS and x509 handling, gzip.
• In-memory book with an append-only archive behind it.
• Derived signals computed server-side and pushed to the dashboard.

Connection and a correct book is typically three to four weeks, most of it spent on reconnection behaviour and edge cases rather than on the happy path. The happy path takes an afternoon; it is the other 5 % of messages that decide whether you can trust the thing.

Frequently asked questions