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.rscrates/common/src/msgbus/mod.rscrates/common/src/cache/mod.rscrates/data/src/engine/mod.rscrates/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
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)
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.