HarvestGroup360
Empowering quantitative research with high-frequency market data and analytics.
"HFT infrastructure" gets searched far more often than it gets explained. Most articles either drown in marketing or hide behind NDAs. Here is the honest, layer-by-layer version — what actually sits between a market event and an order hitting the exchange.
Every serious trading system is a pipeline with two directions: market data flowing in, orders flowing out. Everything below is organized around that loop — and around one merciless constraint we covered in The True Cost of Latency: whoever reacts later, trades against better-informed counterparties.
Before any code runs, geography decides the first race. Serious participants rent rack space in the same data centers where exchanges host their matching engines — Equinix NY4 in Secaucus, LD4 in Slough, and their siblings. Inside the building, exchanges deliberately equalize cable lengths to every cage, so colocation does not buy you an unfair edge over your rack neighbors — it buys you the removal of every disadvantage measured in kilometers. The difference between a colocated system and a cloud server in another region is measured in whole milliseconds: an eternity.
Exchange feeds arrive as dense binary multicast — ITCH, OUCH, proprietary formats — at rates that burst into millions of messages per second. A feed handler's job is to decode that firehose into an order book without falling behind. At this layer, the operating system itself becomes overhead: a conventional network stack costs microseconds per packet in copies and context switches. That is why low-latency shops use kernel-bypass networking (Solarflare/Onload, DPDK, or exchange-grade NICs), where packets travel from the wire into user-space memory directly. The techniques are well documented; the discipline to apply them everywhere is what separates production systems from prototypes.
When events are measured in microseconds, the clock is infrastructure. Packets get timestamped in hardware at the NIC, before software ever touches them, and machines are disciplined with PTP (IEEE 1588) rather than plain NTP — the difference between sub-microsecond and millisecond-level agreement about what "now" means. Without this layer nothing else is measurable: you cannot optimize a latency you cannot trust, and — as we keep repeating on the data side — you cannot merge multi-venue feeds whose clocks disagree.
The outbound path is shorter but more dangerous. Between a strategy's decision and the exchange sit two mandatory stops: pre-trade risk checks (fat-finger limits, position limits, kill switches — the layer we dissected in Pre-Trade Risk Engines in HFT) and the order gateway that speaks the exchange's native protocol. Well-engineered risk checks cost single-digit microseconds; badly engineered ones cost more than the network. Regulators require them for a reason — this is the layer that stands between a software bug and a market incident.
A pattern repeats across nearly every serious shop: the hot path — feed handler, book builder, risk, gateway — lives in C++ (or increasingly Rust, or FPGA for the most latency-critical decode logic), while research, calibration and monitoring live in Python. We wrote about the reasoning in Python vs C++ in Quant Finance: the split is not fashion, it is a boundary between code measured in microseconds and code measured in ideas per week.
Underneath all of it sits the least glamorous layer: capture, normalization and storage of everything the system saw and did. Every latency measurement, every backtest, every compliance report depends on it. This is the layer we have chosen to build in the open — our market-data-normalizer library handles the normalization half of that problem, and its source is public.
A realistic entry ticket for a colocated, kernel-bypass, hardware-timestamped setup starts in the hundreds of thousands of dollars per year once you count rack space, market-data fees, connectivity and the engineers who keep it alive — and scales up from there. That number is exactly why this infrastructure stayed institutional for two decades, and why we think the interesting engineering question of this decade is which layers can be shared, standardized or opened without giving up correctness. That question is, in one sentence, why HarvestGroup360 exists.