Case Studies · BraivIQ AI Engineering Playbook

The Market Data Firehose: What An Investment Bank's Dev Team Must Learn To Build A Low-Latency Feed Handler And Order Book In Code

Ask developers joining an investment bank or trading firm what surprises them most, and a common answer is the market data problem: the sheer, relentless volume of it, and how hard it is to consume correctly and fast. A single venue can push millions of incremental messages per second, and the firm's systems must reconstruct a live order book from that firehose without ever falling behind the market - because a stale or wrong book means bad prices, bad risk and bad fills. This is a genuine, high-stakes pain point, and the tech a dev team must learn to handle it well is specialised and largely invisible from outside the industry: binary protocols like SBE and FAST rather than human-readable FIX on the hot path, direct exchange feeds like ITCH and CME's MDP 3.0, order-book reconstruction on dedicated cores, and latency budgets measured in microseconds heading toward nanoseconds. This playbook is a practical, code-side account of what building a low-latency feed handler and order book actually demands.

September 12, 2026 · 14 min read · By BraivIQ Engineering

Millions/sec - Incremental market data messages a single venue can push - the order book must be rebuilt from this without lagging · SBE / FAST - Binary encodings used on the hot path because parsing tag-value ASCII FIX is too slow for low latency · ITCH / MDP 3.0 - Direct exchange feeds (NASDAQ ITCH, CME MDP 3.0) bypass aggregators for the lowest possible latency · µs → ns - Latency targets moved from sub-millisecond to microseconds, with nanosecond precision the emerging benchmark

Every developer who joins an investment bank or a serious trading firm meets the same humbling reality within their first weeks: the market data problem is far bigger and harder than they imagined. From the outside, consuming market data sounds like subscribing to a price feed. From the inside, it is a firehose - a single venue can emit millions of incremental messages per second, every one of which must be consumed, decoded and applied to a live picture of the market fast enough that the firm's view never lags reality. And the stakes are unforgiving: the reconstructed order book drives pricing, risk and execution, so a book that is stale by even a little, or subtly wrong, produces bad quotes, mis-stated risk and poor fills - real money lost to a software defect. This is one of the genuine, high-stakes pain points of trading technology, and the tooling a dev team must master to handle it well is specialised and almost invisible from outside the industry. As a team that builds trading systems, we think it is one of the most instructive examples of what enterprise, latency-critical engineering really looks like - and this playbook is a practical, code-side account of what building a low-latency feed handler and order book actually demands a dev team to learn.

Lesson One: Human-Readable FIX Is Not For The Hot Path

The first thing a dev team learns is that the protocol most outsiders associate with trading - FIX, the Financial Information eXchange protocol - is not, in its familiar form, how you consume high-volume market data. Classic FIX is a tag-value ASCII format (human-readable key=value pairs), and FIX 5.0 SP2 remains the institutional standard for order flow while many venues still use the very stable FIX 4.4 for connectivity. But parsing tag-value ASCII is comparatively slow, and on a low-latency hot path where you are decoding millions of messages a second, string parsing is simply too expensive. So firms move to binary encodings that preserve FIX's session semantics while replacing the wire format with fixed-offset binary structures - principally Simple Binary Encoding (SBE) and FAST (FIX Adapted for STreaming). The win is that a binary, fixed-offset message can be decoded by reading fields at known byte offsets rather than parsing and allocating strings, which is dramatically faster and, just as importantly, produces no garbage to collect. The lesson for a developer is a general one that applies well beyond trading: when throughput and latency are extreme, the wire format is a first-order performance decision, and human-readable convenience is traded away for machine-efficient binary layouts. Understanding SBE-style fixed-offset decoding is table stakes for market data work.

Lesson Two: Direct Feeds And Reconstructing The Order Book

The second lesson is where the data comes from and what you have to do with it. For the lowest latency, firms take direct feeds via exchanges' proprietary protocols - NASDAQ's ITCH, NYSE's PITCH, CME's MDP 3.0 - rather than consuming a consolidated feed from an aggregator, because every intermediary adds latency and going direct to the source is the fastest path. These feeds are almost always incremental: rather than sending the full order book repeatedly, the venue sends a stream of small updates - add an order, modify an order, cancel an order, execute a trade - and it is the firm's job to apply those updates, in exact sequence, to a locally maintained data structure that reconstructs the current limit order book. This order-book reconstruction is the heart of a feed handler, and it is demanding for two reasons. First, it must be correct and in-sequence: these are incremental updates, so a dropped or out-of-order message corrupts the book, which is why the protocols carry sequence numbers and why handling gaps (detecting them and recovering via a snapshot) is a core part of the design. Second, it must be fast: the data structure representing price levels and their resting orders must support enormous rates of add/modify/cancel with minimal overhead, which drives careful, allocation-free, cache-friendly implementations. A well-built feed handler dedicates cores to this work - one set of cores unmarshals packets and updates book state while that load is isolated from the execution logic - so that decoding the firehose never contends with the decisions made on top of it. Learning to build a correct, fast, gap-aware order book from an incremental feed is the central skill of market data engineering.

Decode binary, not ASCII - use SBE/FAST fixed-offset decoding on the hot path; reading fields at known offsets with no string parsing and no garbage is the performance baseline.
Go direct to the source - take direct exchange feeds (ITCH, PITCH, MDP 3.0) rather than aggregated feeds when latency matters; every intermediary adds delay.
Reconstruct the book in-sequence - apply incremental add/modify/cancel/execute updates in exact order; use sequence numbers to detect gaps and recover via snapshots.
Isolate the load - dedicate cores to unmarshalling and book maintenance so that firehose ingest never contends with execution logic.
Engineer for the cache and the allocator - allocation-free, cache-friendly data structures are what let the book keep up at millions of updates per second.

Lesson Three: Latency Is An End-To-End Engineering Discipline

The third lesson is that latency in this world is not a number you optimise in one place but a budget you defend across the whole path, and the targets are extreme: for many strategies, sub-millisecond is the goal, and nanosecond-level precision is increasingly the benchmark. Hitting those numbers pulls a dev team into territory most application engineers never touch. It means kernel-bypass networking, where packets are delivered straight to user space rather than traversing the operating system's network stack, and increasingly technologies like RDMA (Remote Direct Memory Access), which writes data directly into a remote machine's memory bypassing the CPU. It means caring about CPU cache behaviour, pinning threads to cores, avoiding context switches, and eliminating anything that causes unpredictable pauses - in a garbage-collected language, that means engineering to avoid collection on the hot path; in any language, it means avoiding locks and allocations where you can. The deepest-latency shops go further still, offloading feed processing into FPGAs (programmable hardware) so that decoding and filtering happen in silicon rather than software. The practical point for a dev team is that low-latency market data is a systems-engineering discipline that spans the network card, the operating system, the CPU, memory layout and the language runtime - a long way from ordinary business software, and a genuine specialism to learn. It is also where AI and modern data engineering are now being applied around the edges - for analytics, anomaly detection and monitoring on the captured data - even as the hot path itself stays ruthlessly deterministic.

The pain point, stated plainly: The reason this is a genuine pain point - and not just interesting engineering - is that market data infrastructure is unforgiving in a way most software is not. It has to be simultaneously very fast and exactly correct, under relentless volume, with no room to fall behind, and the cost of getting it wrong is measured in mispriced trades and mis-stated risk rather than a slow page. New developers on a trading dev team must climb a steep and specialised learning curve - binary protocols, direct feeds, order-book reconstruction, gap recovery, and end-to-end latency engineering - that has little overlap with the web and enterprise software most of them came from. Underestimating that curve is the classic mistake. Respecting it - and pairing deep latency engineering with rigorous correctness and testing - is what separates a market data system that can be trusted from one that quietly loses money.

The Bottom Line

The market data firehose is one of the defining engineering pain points of an investment bank or trading firm's technology, and what a dev team must learn to tame it is specialised, demanding and largely hidden from the wider software world. They must learn to decode binary protocols like SBE and FAST rather than parse human-readable FIX on the hot path; to take direct exchange feeds like ITCH and CME MDP 3.0 and reconstruct a live limit order book from millions of incremental, in-sequence updates per second, with gap detection and snapshot recovery; and to defend a latency budget measured in microseconds and increasingly nanoseconds across the network stack, the operating system, the CPU and the language runtime, using kernel bypass, RDMA, careful memory layout and sometimes FPGAs. Above all they must hold two demands at once that most software never has to - extreme speed and exact correctness - because the reconstructed book drives real pricing, risk and execution. It is a steep, genuine learning curve, and respecting rather than underestimating it is the whole lesson. This is precisely the kind of latency-critical, correctness-critical enterprise engineering we specialise in, and it is a superb example of why serious trading technology is a craft of its own.

References & Further Reading

QuantVPS - low latency trading: infrastructure, execution speed and competitive edge explained: https://www.quantvps.com/blog/low-latency-trading
Halkwinds - trading systems architecture: low-latency infrastructure for capital markets: https://www.halkwinds.com/blog/trading-systems-architecture-low-latency-capital-markets
Tuvoc Technologies - low latency trading systems in 2026: the complete guide: https://www.tuvoc.com/blog/low-latency-trading-systems-guide/
Algovantis - optimizing market data acquisition for low-latency algorithmic trading (direct feeds, order book): https://algovantis.com/market-data-acquisition-strategies-for-low-latency-algo-trading/
FIX Trading Community - FIX, SBE (Simple Binary Encoding) and FAST specifications: https://www.fixtrading.org/standards/