TickForge: a low-latency C++20 market data & order execution engine published: false tags: cpp, systemsprogramming, quant, lowlatency

Why I'm building this

Most "low-latency trading" writeups stay at the conceptual level — kernel bypass, lock-free queues, cache-friendly memory layouts — without much code you can actually run, break, and rebuild. I wanted the real thing, or at least a serious foundation of it, so I started TickForge: a C++20 market data and order execution engine, built to understand the architecture behind low-latency trading systems by actually implementing it.

Repo: github.com/td-02/DPDKTrade

This is a foundation-stage project, not a finished trading system — and I want to be upfront about that. The goal right now is a clean, extensible architecture, not a feature checklist.

What's built so far

Fixed-depth L2 order book — bounded memory, deterministic behavior, no dynamic growth on the hot path
Custom 62-byte wire frame for market data and order events — fixed-size, no serialization overhead
Imbalance-based strategy signal — a simple first strategy to validate the book → strategy → risk pipeline end to end
Pre-trade risk guard — a gate between signal generation and order dispatch
Engine layer wiring book, strategy, and risk together into one control flow
Transport scaffolding for both AF_PACKET (baseline) and DPDK-ring (kernel-bypass target), with an initial ring benchmark

Design principles

A few constraints I set for myself up front, because they're the ones that actually matter in this domain:

No dynamic allocation on the hot path. Anything that runs per-tick or per-order needs to avoid malloc/new entirely.
Fixed-size, predictable data structures. The order book and wire protocol are both bounded and pre-allocated rather than growing dynamically.
Modern C++20 throughout, with modern CMake for the build — no legacy build cruft.
AF_PACKET first, DPDK second. Rather than jumping straight to DPDK, I wanted a normal-socket baseline in place first, so the eventual kernel-bypass path has something concrete to benchmark against.

Currently built and tested on WSL2 (Ubuntu 24.04) with GCC/Clang + Ninja.

What's next

Fill out the DPDK-ring transport path and get it talking to the rest of the engine
Proper benchmarking: DPDK-ring vs. AF_PACKET, with real latency histograms rather than a single average
Expand the strategy layer beyond the initial imbalance signal
Docker-based build for portability beyond WSL2

Why I'm sharing this now, mid-build

I'd rather post the architecture while it's still small enough to review in one sitting than wait until it's "done" (it never really is). If you've built order books, market data handlers, or kernel-bypass networking code professionally, I'd genuinely like structural feedback — what would you have done differently at this stage, before more gets built on top of it?

Repo, again: github.com/td-02/DPDKTrade