NAUTILUS / RUST source 3eb18933
Pages

Rust edition: this page follows the live DeepWiki structure but treats the current Rust crates as implementation authority. Non-Rust surfaces are identified at their boundary and are not presented as Rust APIs.

Core Architecture

Relevant Rust source files

  • crates/system/src/kernel.rs
  • crates/common/src/msgbus/mod.rs
  • crates/common/src/cache/mod.rs
  • crates/data/src/engine/mod.rs
  • crates/execution/src/engine/mod.rs

Purpose and Scope

This document describes the fundamental architecture of NautilusTrader, covering the core components that form the foundation of the system. This includes the NautilusKernel orchestrator, the event-driven messaging infrastructure, state management, clock abstractions, and the component lifecycle model. The architecture is common to all runtime environments: backtesting, sandbox, and live trading

The Rust workspace uses a layered design: core/model/common foundations support engines and services, while backtest/live nodes compose those crates into complete execution contexts.

For details on the hybrid implementation, see Rust Crate Architecture. For specific runtime implementations, see Live Trading System and Backtesting System.


System Overview

Technology Stack and Layered Architecture

Layered Nautilus Rust crate dependency map from core, model and common foundations through engines and NautilusKernel to backtest, live, Databento and Interactive Brokers composition.

This Rust edition treats foreign-language bindings as optional outer consumers rather than an architectural layer inside the native engine graph.

Environment Contexts

NautilusTrader supports three primary environment contexts :

Environment Description Clock Type Execution Mode
BACKTEST Deterministic simulation on historical data TestClock BacktestEngine
SANDBOX Real-time data with virtual execution LiveClock OrderEmulator
LIVE Real capital deployment LiveClock ExecutionClient

NautilusKernel: The System Orchestrator

The NautilusKernel is the central dependency injection container that orchestrates engines and infrastructure. It manages the lifecycle of components and ensures they are correctly wired to the MessageBus, Cache, and Clock.

For details, see NautilusKernel and System Orchestration.


Core Engines

DataEngine

The DataEngine manages the flow of market data. It handles fan-in from multiple DataClient instances and fan-out to subscribers It is responsible for bar aggregation and maintaining OrderBook state For details, see DataEngine Architecture.

ExecutionEngine

The ExecutionEngine manages the order lifecycle and routes commands to ExecutionClient adapters It ensures that order fills are correctly aggregated into Position objects For details, see ExecutionEngine Architecture.

RiskEngine

The RiskEngine performs pre-trade validation. Every order command must pass through risk checks (e.g., notional limits, balance checks) before reaching the venue For details, see RiskEngine and Pre-trade Checks.


MessageBus: Communication Patterns

The MessageBus enables decoupled messaging between components, supporting point-to-point, publish/subscribe, and request/response patterns It uses a topic-based routing system (e.g., data.<kind>...)

For details, see MessageBus and Communication Patterns.


Cache and Event Sourcing

Cache

The Cache is the central in-memory store for all trading-related data, including instruments, orders, positions, and accounts

Event Store

The Event Store (via nautilus-event-store) acts as the durable authority for state-affecting history, allowing for replay and recovery

For details, see Cache and State Management and Event Sourcing and Event Store.


Clock System and Time Management

NautilusTrader uses a nanosecond-precision time model The Clock abstraction allows the system to switch between LiveClock (real-time) and TestClock (deterministic simulation) without changing component logic

For details, see Clock System and Time Management.


Component Lifecycle and State Machine

Every major component (Strategies, Engines, Actors) follows a strict finite state machine (FSM)

LiveNode assembly and lifecycle from validated configuration through ordered startup and the running kernel.

For details, see Component Lifecycle and State Machine.


Fixed-Point Precision System

To avoid floating-point errors, NautilusTrader uses a fixed-point arithmetic system for Price, Quantity, and Money types It supports a HIGH_PRECISION mode using 128-bit integers, which is required for certain asset classes like DeFi (18-decimal wei precision)

For details, see Fixed-Point Precision System.