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.

Live Trading System

Relevant Rust source files

• crates/live/src/node/mod.rs
• crates/live/src/node/builder.rs
• crates/live/src/runner.rs
• crates/system/src/kernel.rs

This page describes how the Rust LiveNode orchestrates live trading, manages persistence and recovery, and coordinates data and execution adapters.

For backtesting architecture, see Backtesting System. For information about individual venue integrations, see Venue Adapters. For the underlying kernel shared between live and backtest environments, see NautilusKernel and System Orchestration.

Architecture Overview

The Rust live trading system is built around LiveNode, a native orchestrator running a single-threaded tokio event loop. It drives the system through a tokio::select! loop multiplexing data events, execution events, trading commands, timers, and periodic maintenance tasks.

• NautilusKernel: The core system kernel (shared with backtesting) that initializes and manages all trading engines, portfolio, cache, and message bus

Component Hierarchy (Code Entity Space)

The following diagram maps high-level system components to their specific code entities and identifies the primary communication channels.

Diagram: Live Trading Component Mapping

TradingNode and LiveNode Lifecycle

The live system follows a strict sequence to ensure instruments are cached before execution clients attempt to load them.

Startup Sequencing

1. Connect Data Clients: Instruments arrive as buffered DataEvents
2. Flush Pending Data: Drain the channel receivers until the cache is populated via flush_pending_data
3. Connect Execution Clients: Clients can now find instruments in the cache
4. Reconciliation: Run the initial state alignment

Rust-Native Lifecycle (NodeState)

The LiveNode tracks its lifecycle through the NodeState enum:

State	Discriminant	Description
Idle	0	Initial state before starting
Starting	1	Transitioning through connection phases
Running	2	Actively processing the event loop
ShuttingDown	3	Graceful stop initiated
Stopped	4	Final state after cleanup

For details, see TradingNode Architecture.

Live Engine Configuration

Live engines extend core functionality with asynchronous queue processing and specialized reconciliation logic.

• LiveDataEngine: Handles asynchronous data ingestion. Configurable via LiveDataEngineConfig which includes qsize and graceful_shutdown_on_exception
• LiveExecutionEngine: Manages the live execution lifecycle, including inflight_check_interval_ms, reconciliation settings, and open_check_interval_secs
• LiveRiskEngine: Provides live-specific risk validation with queue management

For details, see Live Engine Configuration.

Execution Reconciliation

Execution reconciliation aligns the venue's actual order and position state with the system's internal state. This is critical for recovering from lost network messages or system restarts.

Reconciliation Flow

Diagram: Execution Reconciliation Procedure

Key Concepts

• In-flight Orders: Orders awaiting venue acknowledgement (SUBMITTED, PENDING_UPDATE, PENDING_CANCEL)
• Submit Outcome Policy: Adapters only emit OrderRejected when the venue proves non-acceptance; transport errors leave orders "in-flight" for reconciliation to resolve
• Reconciliation Events: Rust reconciliation logic under crates/execution/src/reconciliation/ turns venue reports into typed order, fill, and position updates while preserving correlation and deduplication rules.

For details, see State Persistence and Recovery.

Client Factory Pattern

The live system utilizes a builder and factory pattern to register and build venue-specific clients and plugins.

• LiveNodeBuilder: Provides a fluent interface in Rust to add strategies, execution algorithms, and data/execution clients
• LiveNodeBuilder: Coordinates node assembly and registers Rust data and execution client factories.
• Reconciliation Reports: All adapter execution clients follow a standard procedure, calling generate_order_status_reports, generate_fill_reports, and generate_position_status_reports to produce an ExecutionMassStatus

For details, see Client Factory Pattern.