Skip to main content

Trading Infrastructure

Trading is an infrastructure problem before it is a strategy problem. A market making algorithm that arrives at the matching engine 5 milliseconds late loses to one that arrives 1 millisecond late — the mathematical edge is irrelevant if someone else acts on the same information first. In crypto, this infrastructure spans hardware (smart NICs, FPGA gateways, bare-metal servers in Equinix cages), software (order book data structures, execution engine event loops, serialization formats), and networking (fiber routes, kernel bypass, multicast market data feeds).

An order book's core data structure — typically a pair of price-sorted maps, bids descending and asks ascending — must support O(log n) insertion, deletion, and lookup while handling hundreds of thousands of updates per second during volatility spikes. The matching engine applies price-time priority: when a market order arrives, it walks the contra-side of the book, filling against the best resting orders until the order is complete or the book is exhausted. Every microsecond of latency in this loop translates to either missed fills or worse prices.

Co-location — placing your server in the same data center as the exchange's matching engine — reduces network latency from tens of milliseconds (cloud to exchange) to microseconds (cross-connect cable). Major crypto exchanges colocate in hubs like Equinix NY4/NY5 (New Jersey), LD4 (London), and TY3 (Tokyo). For on-chain trading, the latency landscape is different: you're constrained by block time (12 seconds on Ethereum, 400ms on Solana), but you can still optimize transaction propagation — getting your transaction to the block builder or validator ahead of competitors matters when the block fills.

This section covers the full stack of trading infrastructure. We build order books and execution engines in C++ to understand the data structures that power matching at scale. We benchmark Python for crypto trading to quantify when interpreted languages are the bottleneck. We map the co-location landscape at major trading hubs. And we cover the practical debugging that keeps trading infrastructure running — from Kafka networking issues to ML pipeline data leakage.

Research Areas​

  • Order Book Design — Data structures (price-sorted maps, order ID indexes), matching engine algorithms (price-time priority, pro-rata), throughput optimization.
  • Execution Engines — Order processing pipelines, state machine design, persistence and recovery, throughput-latency tradeoffs.
  • Latency Optimization — Hardware (FPGA, smart NICs), kernel bypass (DPDK, io_uring), serialization (FlatBuffers, SBE, Cap'n Proto), network topology.
  • Co-location — Exchange data center geography, cross-connect architecture, latency measurement methodology.
  • Data Infrastructure — Market data pipelines, Kafka and streaming architectures, feature engineering for ML, avoiding data leakage in time-series models.

All Trading Infrastructure Articles​

TRADING INFRASTRUCTURE

Building a Basic Order Book in C++

Step-by-step implementation of a basic order book in C++ with order matching, buy/sell queues, and real-time market depth. Foundation for building trading system infrastructure.

May 12, 2026•4 min read
TRADING INFRASTRUCTURE

Is Python Too Slow for Crypto Trading? We Ran the Numbers.

Everyone says Python is too slow for trading. We benchmarked pure Python vs NumPy vs Pandas on 1M rows, then compared the results to actual on-chain block times. The answer depends entirely on which chain you're trading.

May 12, 2026•8 min read
TRADING INFRASTRUCTURE

Colocation and Latency for Crypto Trading: Same-Provider vs Cross-Provider, Cross-Region

We benchmark latency from EC2 in Tokyo and US East 1 to AWS and GCP Europe endpoints using TCP/TLS timing. From AWS US East 1, connect time to AWS Europe is ~74–104 ms and to GCP Europe ~87–99 ms. From Tokyo to the same endpoints it is ~216–225 ms (AWS) and ~248–262 ms (GCP). Same provider is lower than cross-provider. Here's the methodology and how to run the script yourself.

May 12, 2026•7 min read