Visualising The Order Book In Code: Depth Charts, Heatmaps And Level-2 Market Data Rendering For Trading Interfaces

Depth chart - Cumulative bid and ask curves - the classic view of supply, demand and where liquidity sits  ·  Heatmap - Liquidity over time as colour intensity - revealing resting orders, walls and how they move  ·  Level-2 ladder - The price ladder of bids and asks by level - fast-scrolling, high-frequency, dense with information  ·  Snapshot + delta - Order books are fed as a snapshot then incremental deltas - the model your renderer must track

Most people picture a trading screen as a candlestick chart, but that chart only tells you where the market has been. The order book tells you where it might go: the live, two-sided wall of resting bids and asks that reveals, in real time, how much supply and demand sits at every price and where the liquidity really is. For traders and trading systems, visualising the order book well is enormously valuable - and for engineers, it is one of the more demanding jobs in interface work, because you are rendering a dense, fast-changing dataset that updates many times a second and must stay perfectly smooth while the user reads it. This is a domain BraivIQ specialises in, and this playbook covers how order-book visualisation actually works in code: the underlying data, the visual forms it takes, and the rendering techniques that keep it fluid under a firehose.

The Data: Level-2 And The Snapshot-Plus-Delta Model

Everything starts with the data you are visualising: Level-2 market data, the full depth of the order book showing the resting quantity at each price level on both the bid and ask sides, not just the single best bid and offer (which is Level-1). Feeds almost universally deliver this in a snapshot-plus-delta model: you receive an initial full snapshot of the book, then a continuous stream of incremental updates - a level's quantity changed, a level was added, a level was removed. Your visualisation's first job, before any pixels, is to maintain a correct in-memory model of the book by applying those deltas to the snapshot, in order, without missing or misapplying any - and to detect when you have fallen out of sync (a gap in sequence numbers) and re-request a snapshot to recover. Getting this reconstruction exactly right is the unglamorous foundation of order-book visualisation: if your model of the book drifts from reality, every beautiful chart you draw on top of it is wrong.

The Depth Chart

The depth chart is the classic order-book visualisation, and it is elegant: it plots the cumulative quantity available on each side against price, producing two curves - bids rising as price falls away from the middle, asks rising as price climbs - that meet at the spread in the centre. The shape tells a story at a glance: steep walls mean concentrated liquidity, a wide flat middle means a thin, illiquid market, and large steps reveal big resting orders. Rendering it is a matter of computing the cumulative sums from your book model and drawing two filled area curves, updating as the book changes. The engineering subtlety is that the underlying data changes constantly, so you are recomputing and redrawing these curves continuously - which means, exactly as with price charts, you cannot afford to naively rebuild everything from scratch on every single update if you want it smooth. The depth chart is simple in concept and, done at speed, a real rendering exercise.

The Liquidity Heatmap

The heatmap is the most information-dense and, done well, the most revealing order-book visualisation - and the most demanding to render. It shows liquidity across price (vertical axis) over time (horizontal axis), with the resting quantity at each price-and-time point encoded as colour intensity, so a bright horizontal band is a large resting order sitting in the book, and you can watch walls of liquidity appear, persist, move and vanish over time. It effectively renders the history of the entire order book, which is a lot of data - a grid of price levels by time steps, continuously scrolling as time advances. This is squarely a high-performance rendering problem: you are drawing and updating a large, dense, continuously-scrolling grid of coloured cells in real time, which is exactly the kind of workload that pushes you towards GPU-accelerated rendering (canvas or WebGL) and incremental, append-the-newest-column techniques rather than redrawing the whole grid each frame. The heatmap is where order-book visualisation becomes a serious graphics-engineering challenge.

The Level-2 Ladder

The third core view is the ladder (or DOM, depth of market): a scrolling column of prices with the resting bid and ask quantities shown at each level, often colour-coded, updating in real time. It is dense, fast, and information-rich - professional traders read it like a second language - and rendering it well means updating many rows many times a second while keeping it readable and responsive to interaction (a trader clicks a level to place an order there). The engineering challenges are keeping updates cheap (touching only the rows that changed rather than re-rendering the whole ladder), keeping it visually stable so rapid changes do not make it flicker or jump distractingly, and keeping it interactive under load. The ladder looks like a simple table, but a professional-grade one that stays smooth and readable under a heavy feed, while remaining click-to-trade responsive, is a genuine front-end engineering achievement.

Bringing It Together

A professional order-book visualisation combines these views - depth chart, heatmap and ladder - often synchronised, each drawing from the same continuously-updated book model, each updating smoothly under a relentless Level-2 feed. The architecture that makes it work is the same disciplined pattern that underlies all serious real-time trading interfaces: reconstruct and maintain the book model correctly from snapshot-plus-delta data, recover cleanly when the feed gaps, decouple that data path from rendering, and render each view incrementally with GPU acceleration where the density demands it. Get the data model wrong and everything is subtly false; get the rendering wrong and it stutters when it matters most. Get both right and you give traders a real-time window into market supply, demand and liquidity that a price chart alone can never provide - which is exactly the kind of demanding, high-value trading-interface engineering BraivIQ builds. This is trading charts AI and front-end performance meeting at one of the most information-rich problems in financial software.

References & Further Reading

• SciChart - real-time JavaScript charts and market-depth visualisation with WebGL/WebAssembly: https://www.scichart.com/blog/fastest-chart-libraries-for-quantitative-analysis/
• TradingView - Lightweight Charts (open-source financial charting): https://www.tradingview.com/lightweight-charts/
• OrderBook-rs - a Rust limit order book (the data model behind Level-2 visualisation): https://github.com/joaquinbejar/OrderBook-rs
• LightningChart JS - GPU-accelerated WebGL charts for dense real-time data: https://lightningchart.com/js-charts/
• Investopedia - Level II market data and the order book explained: https://www.investopedia.com/terms/l/level2.asp