Trading Systems Architecture: Low-Latency Infrastructure for Capital Markets

In capital markets infrastructure, latency is not measured in milliseconds anymore. It is measured in microseconds, and increasingly in nanoseconds at the network interface card. The engineering effort behind shaving those intervals off an order's round trip now rivals the complexity of the trading strategies that effort supports. Co-location facilities, kernel bypass networking, custom FIX engines, and purpose-built feed handlers form a stack that most enterprise software teams never need to touch, and that most capital markets firms cannot afford to get wrong.

For engineering leaders evaluating or rebuilding trading infrastructure, the real question is rarely how to get faster in isolation. It is how to sequence investment across networking, messaging, and data handling without quietly trading away the reliability the business depends on. This article walks through that stack layer by layer, and the tradeoffs that separate a fast system from a fast system that stays up.

Table of Contents

• Why Microseconds Matter in Capital Markets
• Co-location and Physical Proximity to the Exchange
• Kernel Bypass Networking and the Death of the OS Network Stack
• FIX Protocol Messaging and Session Architecture
• Market Data Feed Handlers
• Order Matching and Execution Engine Design
• The Latency, Throughput, and Reliability Triangle
• Build, Buy, or Hybrid: Organizational Considerations

Key Takeaways

• In our experience, co-location alone typically removes more round-trip latency than every subsequent software optimization combined, which is why it is usually the first infrastructure decision, not the last.
• Kernel bypass networking approaches such as DPDK or Solarflare OpenOnload commonly cut network stack latency from tens of microseconds to low single digits, but they remove OS-level safety nets that teams must rebuild in application code.
• FIX protocol implementations at the low-latency tier typically diverge substantially from the reference specification, favoring binary encodings like SBE or FAST over tag-value FIX for the hot path.
• Firms commonly run a slower, fully audited failover path alongside the low-latency primary path specifically because the fastest system is rarely the most recoverable one under fault conditions.

Why Microseconds Matter in Capital Markets

The economics are straightforward even if the engineering is not. In latency-sensitive strategies, being a few microseconds behind another participant on the same order book can mean consistently trading at a worse price, or not trading at all. That gap compounds across millions of orders a day, which is why exchanges sell co-location, network vendors sell microwave links between data centers, and trading firms hire engineers whose entire job is removing nanoseconds from an already-fast code path.

Not every capital markets system needs this tier of engineering; a back-office reconciliation platform or a compliance surveillance system has completely different latency requirements than a market-making engine. The architecture described here applies to systems sitting on the critical path between market data arrival and order submission.

Co-location and Physical Proximity to the Exchange

Physical distance is still the single largest latency variable most firms control directly. Placing servers inside or adjacent to an exchange's data center, commonly called co-location, reduces the physical distance signals travel to low single-digit microseconds rather than the milliseconds typical of a remote connection over the public internet. Exchanges typically standardize cross-connect cable lengths, which keeps the playing field level between tenants rather than rewarding whoever gets the rack nearest the matching engine.

Beyond the exchange's own data center, firms trading across venues invest heavily in inter-site connectivity: dedicated fiber, and in some corridors, microwave or millimeter-wave links that beat fiber's speed-of-light-in-glass disadvantage over distance. These links are typically leased from specialized carriers, with contracts specifying latency SLAs and redundant paths for when weather or equipment failure takes a link down.

Kernel Bypass Networking and the Death of the OS Network Stack

A standard Linux network stack, going through the kernel's socket buffers, interrupt handling, and context switches, typically adds tens of microseconds of latency per packet, often more than every other latency source combined for a strategy operating on single-digit-microsecond budgets. Kernel bypass techniques address this directly by letting the application talk to the network interface card without the kernel mediating each packet.

Frameworks like DPDK, Solarflare OpenOnload, and Exablaze exist for this purpose, moving packet processing into user space and often onto dedicated CPU cores that never yield to the scheduler. The tradeoff is real: bypassing the kernel means losing its buffering, retransmission logic, and much of its observability tooling. Teams adopting kernel bypass commonly rebuild lightweight versions of that safety net themselves, since standard tools like tcpdump and netstat see a very different picture once traffic moves off the kernel path.

FIX Protocol Messaging and Session Architecture

The Financial Information eXchange protocol remains the industry standard for order routing and execution reporting, but the version most engineers encounter in documentation, tag-value ASCII FIX, is rarely what runs on a low-latency hot path, since parsing tag-value strings is simply too slow at this tier. Firms typically move to binary encodings, most commonly Simple Binary Encoding (SBE) or FIX Adapted for Streaming (FAST), which preserve FIX's session semantics while replacing the wire format with fixed-offset binary structures a CPU can decode without string parsing.

Session management deserves equal attention. FIX sessions carry sequence numbers, heartbeats, and resend logic designed for reliability over unreliable networks, and that machinery has to coexist with a hot path built for speed. A common pattern is separating the session layer, handling logon, heartbeats, and gap fill, from the application layer that encodes and decodes order messages, so retransmission logic never sits in the latency-critical path.

Market Data Feed Handlers

Feed handlers ingest raw exchange market data, often delivered over UDP multicast, and normalize it into the internal representation a trading engine consumes. This is frequently where firms find their largest unexpected risk, since exchange feeds are typically dense and specific to each venue's own binary format, meaning a feed handler for one exchange rarely transfers cleanly to another.

Reliability here has a particular shape: UDP multicast doesn't guarantee delivery, so feed handlers commonly implement gap detection and recovery, requesting retransmission when a sequence gap is detected. Getting this wrong can mean trading on a stale order book, a materially worse failure mode than being slow. In our experience, firms that treat feed handler correctness as a pure performance problem tend to discover the gap during a real market event.

Order Matching and Execution Engine Design

On the execution side, engineering priorities shift toward deterministic, predictable latency rather than just low average latency. A matching engine that is fast on average but occasionally spikes under load is often worse than one that is consistently a few microseconds slower, because tail latency determines whether an order arrives in time to matter.

This drives specific design choices: single-threaded, lock-free designs for the core matching loop; pinning threads to isolated CPU cores to avoid scheduler jitter; and pre-allocating memory to avoid garbage collection pauses at runtime. Languages with unpredictable pause behavior are typically avoided on this hot path, since the cost of a rare 200-microsecond pause can outweigh months of steady-state optimization.

The Latency, Throughput, and Reliability Triangle

Every decision above trades against the other two corners of this triangle, and pretending otherwise is where trading infrastructure projects go wrong. Kernel bypass buys latency at the cost of the operational tooling the kernel provided for free. Binary FIX encodings buy latency at the cost of interoperability with counterparties still running standard tag-value FIX, and pinning threads to dedicated cores buys predictable latency at the cost of scheduling flexibility under uneven load.

The mitigation most mature firms converge on is running two paths: an aggressively optimized primary path for the common case, and a slower, more conventionally engineered secondary path that takes over during failover or unusual conditions. The secondary path is deliberately not optimized to the same degree, because its job is correctness and recoverability under stress, not speed. Treating these as two different engineering problems produces more resilient infrastructure than chasing one unified fast-and-safe design.

Build, Buy, or Hybrid: Organizational Considerations

Not every firm needs to build this stack from scratch, and few should try to build all of it. Co-location and cross-connects are typically leased rather than built. Feed handlers for major venues are available from specialized vendors and are often a reasonable buy decision unless a firm's edge depends on custom normalization logic. FIX engines exist as mature commercial and open-source options that many firms extend rather than replace.

Where firms typically differentiate is narrower than the whole stack suggests: the matching or execution logic itself, and the monitoring and failover logic that keeps the fast path honest. A pragmatic build-versus-buy conversation starts by identifying which two or three components carry competitive advantage, and treating everything else as infrastructure to source rather than build.

Trading systems architecture is ultimately a discipline of tradeoffs made explicit rather than accidental, treating latency, throughput, and reliability as variables to be balanced deliberately for a specific strategy and risk appetite, not a single scoreboard to maximize. If you're evaluating a rebuild of trading infrastructure, or scoping a feed handler, matching engine, or FIX gateway project, our team at Halkwinds works through exactly these tradeoffs with capital markets clients; reach us at https://www.halkwinds.com/contact to talk through your architecture.

Frequently Asked Questions

What is considered low latency in a trading system today?

Definitions vary by asset class, but for equities and futures market making, the hot path from market data arrival to order submission is commonly targeted in the single-digit to low double-digit microsecond range. Fixed income and less liquid derivatives markets typically tolerate more, often tens to hundreds of microseconds.

Is co-location necessary for every trading strategy?

No. Co-location matters most where being first to react to a market data event determines profitability, such as market making or latency arbitrage. Strategies operating on longer horizons, such as many portfolio execution algorithms, typically get little benefit from it relative to its cost.

Why not use standard tag-value FIX everywhere for simplicity?

Standard tag-value FIX remains appropriate, and is often required, for counterparty-facing order flow where interoperability matters more than raw speed. It becomes a bottleneck specifically on the internal hot path, where every microsecond of parsing overhead is measurable against a strategy's edge.

What happens when a kernel bypass network path fails?

This is precisely why firms typically maintain a conventional networking path as a fallback. If the kernel bypass path or its dedicated hardware fails, traffic commonly fails over to a standard network stack, at the cost of latency but not correctness, so trading continues in a degraded but safe mode rather than stopping entirely.

How should a firm start modernizing legacy trading infrastructure?

In our experience, the most effective starting point is profiling the existing system to find where latency and reliability risk actually concentrate, rather than assuming co-location or kernel bypass are the first investments needed. Feed handler correctness and matching engine determinism are frequently bigger risks than raw network latency in systems that haven't been re-architected recently.