Starting From the Outside In
Most explanations of trading infrastructure start at the order and work backward toward data. This gets the causality wrong. In any real system, market data arrives first. The entire chain of feed handlers, normalizers, routing engines, and order gateways exists to process that data and turn it into fills. Starting from the data gives you a cleaner picture of where latency and complexity actually accumulate.
Layer 1: Feed Handlers
Feed handlers are the entry points where raw exchange data arrives. A feed handler does three things: receives network packets (via kernel bypass like DPDK or via standard sockets depending on latency requirements), parses the protocol (ITCH, SBE, FAST, proprietary binary), and publishes parsed messages to downstream consumers.
The complexity that concentrates here is protocol diversity. Each venue speaks its own dialect. NASDAQ ITCH 5.0 encodes order events as fixed-length binary records with a message type byte. CME MDP 3.0 uses FIX/SBE framing with incremental refresh semantics. ICE has its own binary format. A shop covering 8-10 venues runs 8-10 different feed handler implementations, each with its own parser, its own gap detection logic, and its own sequencing rules.
Feed handler performance matters because everything downstream is only as fresh as what the feed handler delivers. In co-location environments, well-implemented feed handlers running on kernel-bypass NIC hardware parse and publish messages within 1-3 microseconds of packet arrival. Over standard internet connectivity, you are measuring in milliseconds and the variance is high.
Layer 2: Order Book Reconstruction
Between the raw feed and your trading logic sits the order book. Feed handlers emit raw events: add order, modify order, cancel order, execute. The order book layer applies these events in sequence to maintain a current view of the bid and ask at each price level.
Getting this right is harder than it looks. Exchanges send order book events, not snapshots. Your state is the accumulation of all events since you subscribed or since your last recovery. If you miss a single event due to a sequence gap, your entire book state becomes invalid until you re-sync. Most serious implementations maintain a gap detection window and trigger an implicit or explicit recovery when a gap is confirmed.
Order book reconstruction is memory-intensive and cache-sensitive. A standard equities book with 10 levels on each side uses a small amount of memory, but updating it on every incoming event with hot-path latency constraints means your data structures need to be designed for cache line alignment and minimal pointer chasing. Price level arrays indexed by a compact price encoding typically outperform hash maps or sorted containers here.
Layer 3: Normalization and the Internal Bus
If you have multiple feed handlers each producing venue-specific message formats, something needs to translate them into a common internal schema before your routing logic can compare quotes across venues. This is the normalization layer.
The tradeoff is straightforward: normalization adds a processing step but enables the rest of the stack to remain venue-agnostic. Without it, every component downstream needs to understand every venue's quirks. With it, you pay a small CPU cost and gain maintainability. For latency-sensitive paths, the normalization step should be zero-copy where possible: translate field by field in-place rather than allocating a new message object.
The internal bus connecting these layers in latency-critical systems is typically a shared-memory ring buffer or a published-subscribe system built on lock-free queues. The goal is to move messages between feed handler and router without any kernel involvement. System call overhead in the critical path is measured in microseconds.
Layer 4: The Smart Order Router
The routing engine receives a normalized, real-time view of the market across venues and makes decisions: which venue to target, whether to split an order, and what order type to use. This is where market microstructure knowledge matters most. A routing engine that only looks at the best bid and offer misses queue position, historical fill rate variance at different venues, and dynamic spread patterns that vary through the session.
Routing logic is stateful. It tracks venue health (are messages arriving? is the connection alive?), fill history per venue per symbol, and current market conditions. In our architecture, the routing engine maintains a score vector per venue that is updated on every incoming quote and adjusted based on post-trade fill outcomes. The score computation runs on every routing decision and needs to complete in under a microsecond to stay off the critical path.
Layer 5: Order Gateway and Execution
Below the router sits the order gateway: the component that translates routing decisions into exchange-specific order submission messages and manages the session lifecycle. For FIX-based venues, this means maintaining FIX session state, handling heartbeats, and managing sequence numbers. For binary protocol venues, it means maintaining per-session connection state and handling order acknowledgments.
The gateway is where your stated latency numbers come from for external benchmarking purposes. Order-to-ACK latency measures from the moment the gateway sends the order message to the moment it receives an execution acknowledgment. Everything upstream contributes to your routing decision latency. Everything downstream from the gateway is in the exchange's hands.
Where Complexity Actually Concentrates in Practice
In practice, the layers that cause the most operational pain are not the ones that cause the most theoretical complexity. Feed handler diversity (too many formats, too many venues) creates maintenance burden but rarely produces production incidents if the code is solid. The order book layer produces incidents: a gap handling bug that causes stale state to persist silently is extremely difficult to detect and produces unexplained fill quality degradation rather than obvious errors.
The routing engine produces P&L-visible problems when its scoring model is miscalibrated. A venue that starts exhibiting higher adverse selection than historical averages should cause the router to downweight it automatically. If that feedback loop is slow or absent, you route into poor conditions and blame slippage on market conditions that are actually detectable in your own fill data.
This is why we treat post-trade analytics as part of the infrastructure stack, not an optional add-on. The data to improve routing quality is in your execution record. Getting it back into the routing model in near-real-time is an infrastructure problem, not just a quant problem.