Quant Trading with C++

This book teaches you to design and implement low-latency trading infrastructure in modern C++ with explicit attention to correctness, memory behavior, and measurable performance. By the end, you will have a complete trading stack: market data handling, order book, order management, strategy framework, risk gateway, simulation harness, and production operations.

Who This Book Is For

You are a developer with solid C++ fundamentals who wants to build institutional-grade trading systems. You have working proficiency in modern C++ including templates, RAII, and move semantics. You are comfortable with networking, concurrency, and performance debugging basics. You have a basic understanding of financial markets, order types, and market data.

How This Book Is Organized

Chapters 1 and 2 establish the low-latency mindset and memory discipline. Chapters 3 and 4 build the market data path from network to normalized events. Chapters 5 through 7 construct the order book, OMS, and strategy/risk layer. Chapters 8 and 9 add simulation and evidence-driven optimization. Chapter 10 closes with production hardening.

Each chapter reuses the interfaces and contracts defined by earlier chapters. The stack grows from the network edge inward.

How to Use This Book

Read linearly. The system is designed so that each chapter's output becomes the next chapter's input. All code uses modern C++ (C++17/20). Work through the exercises — they extend the core implementations and build your intuition for performance-conscious design.

Low-Latency Architecture in C++

A team at a mid-frequency proprietary trading firm finishes a new market-making strategy. In simulation, the system processes market data updates, recalculates fair value, and generates quotes in under 5 microseconds. The backtest shows strong edge. The team deploys to production on a Tuesday morning.

By Wednesday, they have lost money on every session. The P&L is not catastrophic, but it is consistently negative. The strategy logic has not changed. The signals are identical. The fills are real, and they are worse than simulation predicted on nearly every trade.

The root cause takes two weeks to find. In production, the system shares a server with a logging subsystem that allocates memory on the hot path. Every 200 milliseconds, the allocator triggers a minor page fault. That page fault stalls the strategy thread for 15 to 40 microseconds — long enough for the market to move past their quoted price. Their fills cluster on the wrong side: they buy when the market is already ticking up and sell when it is already ticking down.

The strategy was correct. The architecture was not. The system had no latency budget, no measurement discipline, and no isolation between the hot path and everything else. This chapter builds the architectural vocabulary and engineering habits that prevent that failure.

• Define latency budgets, throughput targets, and determinism requirements for a trading system
• Identify and isolate the hot path in a trading application
• Connect specific C++ language features to low-latency design goals
• Apply a correctness-first, measurement-driven approach to performance engineering
• Distinguish between architectural decisions that belong in design and micro-optimizations that belong in profiling

Why This Matters

Low-latency trading systems are unusual software. Most applications optimize for throughput, developer productivity, or feature velocity. A web service that responds in 50 milliseconds is considered fast. A trading system that responds in 50 microseconds may be too slow.

This difference in scale changes everything about how you design, build, and operate software. Decisions that are harmless in a typical application — heap allocation, virtual dispatch, uncontrolled logging — become performance hazards in a system where every microsecond of jitter can turn a profitable strategy into a losing one.

The architectural mindset matters more than any individual optimization. A system with a clean hot path, explicit ownership semantics, and instrumented latency measurement will outperform a system built from cleverly optimized components that lack structural discipline. What matters is not raw speed at any single point, but consistent, predictable performance across the entire critical path.

This chapter establishes the framework that every subsequent chapter builds on. When Chapter 3 designs a feed handler, it will assume you understand why the handler must avoid allocation. When Chapter 5 builds an order book, it will assume you know how to measure whether the book update meets its latency budget. When Chapter 9 profiles the full stack, it will assume you can distinguish between architectural bottlenecks and micro-optimization opportunities.

The concepts here are not theoretical. They reflect how institutional trading firms design their systems. If you are preparing to build trading infrastructure, interview for a quantitative development role, or evaluate the performance characteristics of an existing system, this chapter gives you the vocabulary and the reasoning tools to do that work.

Latency Budgets and Throughput Goals

Intuition

A latency budget is a contract between your system and the market. It states: given a market data event, the system must produce a response within a specified time. That time is not a suggestion. It is a hard constraint that determines whether your strategy captures the edge it was designed to capture.

Without a latency budget, performance conversations devolve into vague claims. "The system is fast" is not actionable. "The tick-to-order path must complete within 10 microseconds at the 99th percentile" is actionable. It tells you what to measure, where to measure it, and when to stop optimizing.

Defining the Budget

A latency budget decomposes the critical path into stages and assigns a time allocation to each. For a market-making system, the stages might look like this:

• Network receive — NIC to userspace buffer — 1–3 μs
• Parse — Binary protocol to internal struct — 0.5–1 μs
• Book update — Apply update to order book — 0.5–1 μs
• Strategy — Recompute fair value and quotes — 1–3 μs
• Risk check — Validate order against limits — 0.3–0.5 μs
• Serialize + send — Internal order to wire format — 0.5–1 μs
• Total — Tick-to-order — 4–10 μs

The key idea is that each stage gets its own allocation, and the sum of the allocations defines the system's total latency target. If the parsing stage consistently takes 3 microseconds instead of 1, it does not matter that the strategy stage is fast. The budget is blown.

Percentiles, Not Averages

Average latency is the wrong metric for trading systems. A system with 2-microsecond average latency and 500-microsecond tail latency at the 99.9th percentile will lose money on the tail events — and those are often the events that matter most, because they coincide with high-volatility market conditions when spreads are tightest and adverse selection is highest.

In practice, trading firms care about three percentile measurements:

• p50 (median): baseline system performance under normal conditions
• p99: tail latency that affects a meaningful fraction of events
• p99.9: worst-case behavior that determines whether the system can survive volatility spikes

A well-designed system has a tight distribution. The ratio between p99.9 and p50 should be small — ideally less than 5x. A large ratio indicates jitter, which usually points to an architectural problem: garbage collection pauses, memory allocation on the hot path, context switches, or lock contention.

Throughput as a Separate Axis

Throughput — the number of events the system can process per second — is distinct from latency. A system that processes one event in 5 microseconds does not necessarily sustain 200,000 events per second. Batching, queuing, and resource contention all create gaps between single-event latency and sustained throughput.