Rust replacement: this page maps the native crate graph directly. Binding layers from the source page are outside this edition.

Pure Rust Crate Architecture

NautilusTrader’s Rust implementation is a collection of focused crates, not one monolithic SDK. Applications compose the crates they name directly while Cargo resolves the remaining kernel components transitively. The model crate supplies shared domain identity; live and backtest runtimes assemble the same data, trading, portfolio, risk, and execution concepts for different environments.

Foundation crates

Crate	Responsibility
nautilus-core	clocks, time, UUIDs, precision support, collections, correctness primitives
nautilus-model	market data, instruments, identifiers, prices, quantities, orders, positions, accounts
nautilus-common	cache contracts, message bus, actors, logging, component infrastructure
nautilus-serialization	optional Arrow and serialization codecs
nautilus-network	outbound HTTP, WebSocket, TCP, rate limiting, and reconnect support

The dependency direction begins with core, then model, then common services. Provider, runtime, and engine crates depend inward on those shared values.

Engine and trading crates

Crate	Responsibility
nautilus-data	DataEngine, subscriptions, aggregation, order books, provider routing
nautilus-trading	Actor and Strategy lifecycle, commands, and event callbacks
nautilus-portfolio	account, position, order, valuation, and analyzer state
nautilus-risk	pre-trade checks and risk command processing
nautilus-execution	execution routing, reconciliation, OMS behavior, reports
nautilus-analysis	portfolio statistics and performance analysis
nautilus-indicators	reusable technical indicators

These crates exchange nautilus-model values directly. An application should not introduce parallel quote, trade, bar, order, position, or account types inside this kernel.

Runtime composition

nautilus-system owns NautilusKernel. Its construction path creates the cache and message bus, then portfolio, risk, execution, emulator, data engine, and trader. nautilus-live wraps that kernel in LiveNode and adds provider-client factories, connection ordering, reconciliation, the live event loop, and shutdown. nautilus-backtest composes deterministic simulation around the same model and trading contracts.

Sources: crates/system/src/kernel.rs, crates/live/src/node/mod.rs, crates/live/src/node/builder.rs, crates/backtest/src/engine.rs, crates/backtest/src/node.rs.

Provider adapters

Adapters terminate external protocols at a narrow boundary and emit canonical Nautilus values.

This edition supports:

• nautilus-databento for DBN loading, historical requests, and live market data.
• nautilus-interactive-brokers for IB market data and execution.

The adapter crates depend on model, common, live, network, and execution capabilities as required. Application code should use their public clients and factories rather than copy their decoders, symbology, reconnect, or reconciliation behavior.

Persistence and replay

nautilus-persistence provides explicit Arrow, Feather, Parquet, object-store, and query components. nautilus-event-store records ordered state-affecting history, run manifests, recovery metadata, and market-history cursors. Neither automatically creates a QuestDB integration. A custom storage adapter should persist canonical Nautilus values and keep provider sequence, coverage, and commit metadata outside the market payload.

Concurrency model

The native live node is deliberately single-threaded at the engine boundary and contains Rc<RefCell<_>> state. Provider and runner channels deliver work into that owner. Do not assume the kernel is Send across arbitrary executors. Network or storage work attached to synchronous callbacks must enqueue quickly and must not block the engine.

External message-bus egress is explicitly allowed to drop when a channel is full. It is therefore an observability or integration surface, not an authoritative persistence boundary.

Sources: crates/live/src/runner.rs, crates/common/src/msgbus/backing.rs, crates/common/src/msgbus/external/mod.rs.

Feature consistency

Feature flags change real contracts:

• high-precision changes fixed-point widths and Arrow schemas.
• live brings node and system composition into adapters such as Databento.
• streaming enables persistence-backed backtest data flow where supported.
• Binding-only feature flags are outside this native Rust edition.

All direct Nautilus crates must resolve from one version and source revision. Cargo feature unification does not protect an application that compiles duplicate versions of nominally identical model types.