Shaving a millisecond off a trade execution path used to be a meaningful achievement. Now the unit that matters is the microsecond, and in the busiest venues, the nanosecond. A firm that can see a price change and act on it 5 microseconds before a competitor captures the spread before anyone else even knows it existed. That gap is small enough to be invisible to a human and large enough to determine which firm gets filled and which one gets the stale price.
This piece is about where that time actually goes in a trade execution path, and where edge computing can and cannot claw it back. It is a different problem from scaling a fintech platform to handle more users or more regions, which is covered in cloud architecture for fintech scalability. High-frequency trading infrastructure is not solving for throughput or reliability at scale. It is solving for one thing: the shortest possible path between a market event and an order hitting the exchange matching engine.
Why Microseconds Decide Who Wins the Trade
Market data moves at the speed of light through fiber, which is roughly two-thirds the speed of light in a vacuum. Over a 100 kilometer run, that is a difference of tens of microseconds depending on the route. A strategy that reacts to a price change on one exchange and sends an order to another is in a race against every other firm doing the same thing, and the exchange’s matching engine will fill the first order that arrives, full stop.
This is why the industry built an entire infrastructure layer around proximity and determinism rather than raw compute power. A firm with a mediocre strategy and a 3 microsecond advantage in the execution path will out-trade a firm with a brilliant strategy and a 50 microsecond disadvantage, in the specific class of trades where speed is the edge. Not every strategy depends on this. Market making, latency arbitrage, and some forms of statistical arbitrage do. Longer-horizon strategies generally do not, and the infrastructure spend described here would be wasted on them.
The Latency Stack: Where Time Actually Gets Lost
Total latency in a trade execution path breaks into distinct segments, and each one has a different ceiling on how much can be shaved off.
- Market data ingestion: the time from a price update leaving the exchange to it reaching the trading application’s memory.
- Processing time: the time the strategy logic takes to decide on an action once it has the data.
- Order transmission: the time from decision to the order packet leaving the firm’s infrastructure.
- Exchange-side handling: the time the exchange’s own gateway and matching engine take to accept, validate, and act on the order.
Most firms assume processing time is where the gains live, since that is the code they control most directly. In practice, network transit and serialization overhead, the physical distance data travels plus the time spent packing and unpacking it into transmittable form, often dwarf the actual decision logic. A well-tuned strategy can execute its decision in under a microsecond. Getting the data to it and the order away from it reliably costs several times that, which is exactly why the physical and network layers get so much engineering attention relative to the algorithm itself.
Colocation vs Edge Computing: Two Different Bets on Proximity
Colocation means renting rack space inside or immediately adjacent to the exchange’s own data center, so the cable run between a firm’s server and the exchange’s matching engine is as short as physically possible, sometimes a few meters. This has been the standard approach in equities and futures trading for over a decade, and exchanges like CME and NYSE sell colocation space specifically because every firm wants the same thing: the shortest wire.
Edge computing, in the trading context, usually refers to something slightly different: deploying compute closer to the source of data or the point of decision when that point is not inside a single exchange’s data center. This matters more in markets that are fragmented across venues, in cross-asset strategies that need to react to signals from multiple geographically separate sources, or in FX and crypto markets where liquidity is split across dozens of venues with no single physical center to colocate near.
The two are not competing solutions to the same problem. Colocation wins when the race is against a single, known opponent at a single, known location, the exchange’s matching engine. Edge computing wins when the race involves synthesizing signals from multiple locations and acting on the composite faster than a purely centralized architecture could. A firm trading a single instrument on a single exchange has a straightforward colocation decision. A firm running cross-venue arbitrage has to decide where to place edge nodes, how many, and how to keep them synchronized, which is a materially harder architecture problem.
What an Edge Node for Trading Actually Looks Like
An edge node in this context is not a generic edge server running containerized microservices. It is a stripped-down, purpose-built machine that does as little as possible, because every layer of software between the network card and the trading logic adds latency.
A typical setup includes:
- A bare-metal server with no hypervisor, since virtualization adds scheduling overhead that is unacceptable at this timescale.
- A minimal or custom operating system kernel, often with unnecessary services, interrupts, and even parts of the standard networking stack disabled or bypassed entirely.
- Direct connections to market data feeds, frequently via dedicated fiber rather than shared internet links.
- Hardware timestamping at the network interface, so the firm has an accurate record of exactly when each packet arrived, independent of the processing delays further up the stack.
- Co-located clocks, usually GPS-disciplined, kept synchronized across all edge nodes so that timestamps from different locations can be compared meaningfully.
The node’s job is narrow: receive market data, run a decision function, and emit an order, all with as few operations and as little software abstraction in between as the firm can tolerate. Anything general-purpose, logging, monitoring overhead, orchestration layers, gets pushed off the critical path and handled asynchronously elsewhere.
Network Topology and the Physics You Can’t Code Around
No amount of software optimization beats the speed of light. If an edge node sits 50 kilometers further from the exchange than a competitor’s, that firm is giving up roughly 250 microseconds round trip on fiber alone, an amount no clever algorithm recovers. This is why network topology decisions get made years in advance and rarely get revisited casually.
Firms that need to react to price moves across multiple exchanges invest in dedicated point-to-point links between those exchanges’ data centers, sometimes laying private fiber, sometimes leasing capacity on microwave networks. Microwave is counterintuitive to most engineers because it is lower bandwidth and more weather-sensitive than fiber, but it is faster in a straight line, since microwave travels through air at close to the speed of light while fiber’s refractive index slows light down by around 30 percent. For the specific use case of getting a price signal from Chicago to New York microseconds faster than a competitor, that tradeoff is worth it, which is why microwave towers line that corridor.
The topology question extends to how edge nodes talk to each other. A mesh where every node talks directly to every other node adds coordination overhead. A hub-and-spoke model centralizes decision-making but adds a hop. Most serious deployments use a hybrid: edge nodes make local, fast decisions independently, and a slower central system handles risk limits, position reconciliation, and anything that does not need to happen in microseconds. Getting that split wrong, pushing too much decision logic to the center, is one of the more common architecture mistakes in this space.
Hardware Choices That Matter at the Edge: FPGAs, Kernel Bypass, and Smart NICs
Software running on a general-purpose CPU, even well-optimized software, has an operating system and a kernel network stack standing between the network card and the application. Each of those layers introduces context switches, interrupts, and buffer copies, and each one costs time measured in microseconds, which is an eternity at this scale.
Kernel bypass techniques, such as DPDK or Solarflare’s OpenOnload, let the application talk directly to the network interface card, skipping the operating system’s networking stack entirely. This alone can cut latency from the tens of microseconds down to single digits for market data ingestion and order transmission.
FPGAs, field-programmable gate arrays, go a step further by moving the actual decision logic into hardware. A strategy implemented as an FPGA circuit executes in nanoseconds because there is no instruction fetch, no branch prediction, no software overhead of any kind, just signal propagation through logic gates. The tradeoff is that FPGA development is slow and inflexible compared to writing software. Changing a strategy means re-synthesizing and redeploying hardware logic, a process that takes hours or days rather than the minutes it takes to push a code change. Firms that use FPGAs typically reserve them for the most latency-critical, most stable parts of a strategy, the parts that do not change often, and keep everything else in software that can iterate quickly.
Smart NICs sit between these two extremes, offloading specific functions like packet filtering, timestamping, or even simple order logic onto the network card itself without requiring a full FPGA development cycle. They have become a popular middle ground for firms that want some hardware acceleration without committing to the FPGA development overhead.
Where Edge Deployments Break Down and the Tradeoffs Nobody Advertises
None of this comes free, and vendors selling colocation racks and FPGA toolchains have little incentive to walk through the failure modes.
Edge nodes running stripped-down operating systems and bypassing standard monitoring tools are harder to observe. A firm that has disabled much of the normal logging and telemetry to save microseconds has also made it harder to diagnose why an order was rejected or a strategy misbehaved, which becomes a real problem during an incident at 2am.
Synchronization across geographically distributed edge nodes is genuinely hard. Clock drift between GPS-disciplined clocks is small but nonzero, and when strategies are making decisions based on comparing timestamps from multiple locations, even nanosecond-level drift can produce subtly wrong decisions that are difficult to detect until a post-trade analysis flags an anomaly.
The hardware itself is expensive and depreciates fast. FPGA talent is scarce and costly to hire, and a strategy encoded into hardware logic is harder to audit, harder to version control in the way software teams are used to, and harder to hand off when the person who wrote it moves on.
And proximity has diminishing returns. Once a firm is colocated in the same facility as the exchange, with a cable run measured in meters, further gains come from shaving nanoseconds off processing logic, which requires disproportionately more engineering effort for disproportionately smaller returns. At some point, the marginal microsecond costs more than the trades it wins are worth, and the honest answer for most firms evaluating this infrastructure is that the spend only makes sense for the specific strategies where speed is the actual edge, not a secondary benefit.
Firms evaluating this path should size the infrastructure to the strategy, not the other way around. A latency budget built around the most time-sensitive trade in the book will overshoot the needs of everything else running on the same system, and the cost of maintaining that budget compounds every year the hardware stays in production.