Building a trading framework in Rust: the initial plan

This project is not just about code. It’s a structured journey into the world of trading systems, with a strong focus on high-frequency trading (HFT), system design, and code quality. We’ll build an open-source framework in Rust that reflects the practices of production-grade software: modular, testable, observable, and fast.

Rust is an ideal tool for this purpose. It offers control over performance without compromising safety, and allows us to express low-latency architectures in a way that’s explicit and reliable.

Our goal is to learn by building. This includes a professional library for trading in Rust, and a set of articles that teach, explain, and reflect on every major concept and design decision.

The vision

We aim to create:

  • A learning resource for engineers who want to go deep into HFT and low-latency trading.
  • A modular Rust library that abstracts common trading components (market data, execution, strategy logic, risk management).
  • A series of articles that show, step by step, how to build, measure, and reason about every part of a trading system.
  • A professional-grade architecture that can serve as a base for real-world experimentation.

This is not a toy project. From the start, we’ll use good engineering practices: benchmarks, CI, abstractions with clear boundaries, latency metrics, logging, and thoughtful design patterns.

The roadmap

The journey is structured in five stages. Each one brings new components, new design constraints, and new opportunities to optimize.

1. Foundations

Objective: set up our environment and understand the basics of market mechanics.

Topics:

  • Market structure: what is a limit order book? what does it mean to be a market maker or a taker?
  • Basic order types, spread, depth, latency.
  • Installing Rust and preparing the system for low-latency workloads.
  • Picking an async runtime (or going fully sync), performance benchmarking with criterion, building flamegraphs.

Deliverables:

  • A toy exchange simulator with a naive matching engine.
  • Project layout with workspaces, logging, config handling, and basic tests.

2. Market data ingestion

Objective: build a fast and modular market data feed processor.

Topics:

  • How to receive data from exchanges: WebSocket, REST, UDP, or FIX.
  • Efficient JSON/Protobuf decoding.
  • Ring buffers and lock-free queues for ingestion.
  • Designing a clean feed abstraction to allow real/simulated data interchangeably.

Deliverables:

  • A market_data crate with multiple feed types and a performance benchmark suite.

3. Strategy engine

Objective: create a strategy engine that works both in simulation and live environments.

Topics:

  • Event-driven architecture and trait-based strategies.
  • Managing state: snapshots, time series, internal caches.
  • Testing strategies offline: input recording, replay systems, property-based testing.

Deliverables:

  • A strategy_engine crate with basic built-in strategies (e.g. VWAP, momentum).
  • A simulation harness to run strategies offline on recorded data.

4. Order execution and risk

Objective: send orders safely, track their status, and handle rejection, risk, and reconciliation.

Topics:

  • Design of an execution API: sync vs async, traits vs channels.
  • Sending to real or simulated exchanges.
  • Risk management hooks: position size, exposure, cancel-on-disconnect, kill-switch logic.

Deliverables:

  • An execution crate that abstracts exchange interaction.
  • Risk controls embedded in the order flow.

5. Infrastructure and operations

Objective: make the system observable and production-ready.

Topics:

  • Metrics with tracing, Prometheus, and histogram-based latency measurement.
  • Configuration management and error handling.
  • Docker setup, simulation runners, and dashboards.

Deliverables:

  • A full containerized version of the system with monitoring tools.
  • Real-time metrics dashboard and structured logs.

Design principles

Throughout the project we will follow a few core ideas:

  • Performance matters: we’ll profile early and often.
  • Clean boundaries: each component will be abstracted in its own crate.
  • Testability: everything can be simulated, tested, and mocked.
  • Observability: logs and metrics are part of the design, not an afterthought.
  • Code quality: even in high-performance systems, correctness comes first.

Who is this for?

This project is written for engineers who:

  • Are interested in algorithmic and quantitative trading.
  • Want to learn HFT system architecture by building from scratch.
  • Already know Rust and want to apply it to a challenging, real-world domain.
  • Care about software quality, clean design, and performance.

Next steps

The next article will walk through the technical setup: how to structure the project, how to write a simple market simulator, and how to prepare for the challenges ahead.

This is the beginning of a long journey. We’ll keep the code clean, the benchmarks honest, and the lessons practical.