Rust adaptation: configuration is represented by typed Rust structs, builders, validation methods, and explicit runtime composition.

Configuration System

Nautilus Rust crates define configuration close to the component that consumes it. Builders provide defaults and construction ergonomics; validation rejects malformed or unsupported values before runtime ownership begins. There is no single untyped configuration dictionary in the native path.

Configuration layers

Layer	Representative types	Source
Kernel	NautilusKernelConfig and environment identity	crates/system/src/config.rs
Cache and message bus	CacheConfig, MessageBusConfig	crates/common/src/config.rs
Portfolio	PortfolioConfig	crates/portfolio/src/config.rs
Backtest	BacktestEngineConfig, BacktestDataConfig, venue configs	crates/backtest/src/config.rs
Live node	LiveNodeConfig and engine sub-configs	crates/live/src/node/config.rs
Databento	loader, historical, live, and client configs	crates/adapters/databento/src/data.rs, crates/adapters/databento/src/factories.rs
Interactive Brokers	connection, data, execution, and gateway configs	crates/adapters/interactive_brokers/src/config.rs

Builders and defaults

Configuration types generally derive or expose builders. Defaults are meaningful operating choices rather than proof of suitability for every deployment. Callers should construct configuration once at the process boundary, validate it, then pass owned values into node builders and client factories.

LiveNodeConfig contains identity, lifecycle timeouts, infrastructure settings, engine settings, client maps, and optional event-store configuration. BacktestEngineConfig and BacktestDataConfig define deterministic simulation and data-loading behavior.

Validation

Validation has two responsibilities:

1. Reject invalid values such as malformed identifiers, negative intervals, invalid rate-limit strings, or unsupported precision.
2. Reject fields that exist in the shared config model but are not wired by the current native runtime.

The live configuration’s validate_runtime_support method collects multiple failures, including unsupported queue sizing, streaming, emulator, snapshot, and database-purge fields. A successful deserialization is therefore not enough; runtime-support validation is part of construction.

Provider configuration

Client factories receive typed or boxed configuration and resolve provider-specific clients. Databento configuration selects dataset, schema, symbology, historical ranges, and live subscriptions. Interactive Brokers configuration covers gateway/TWS connection identity, account behavior, market data, and execution reconciliation.

Credentials should come from the application’s secret boundary. Configuration logs, manifests, and browser responses must not contain provider secrets.

Feature-controlled configuration

Cargo features determine whether corresponding configuration can be used:

• nautilus-databento/live enables live-node and system integration.
• nautilus-databento/high-precision aligns model and optional serialization precision.
• nautilus-interactive-brokers/execution enables execution and networking.
• nautilus-interactive-brokers/examples enables native LiveNode examples.
• nautilus-backtest/streaming activates persistence-backed data streaming.

Treat feature selection as part of the configuration contract and lock it alongside the source revision.

Composition rule

Configuration describes requested behavior; builders and factories create owners. It does not itself open sockets, create databases, start event-store runs, or register strategies. Those effects occur when BacktestNode or LiveNodeBuilder consumes validated configuration.