Rust adaptation: factories are documented from crates/common/src/factories/client.rs and the selected adapter implementations.

Client Factory Pattern

Client factories separate provider configuration and construction from LiveNode orchestration. The node builder stores factory entries, creates clients during build, and registers the resulting adapters with the owning data or execution engine.

Factory traits

DataClientFactory creates data clients from provider configuration and shared runtime dependencies. ExecutionClientFactory does the same for live execution clients. Registries associate configuration keys with concrete factories so the node can remain provider-agnostic.

Sources: crates/common/src/factories/client.rs, crates/live/src/node/builder.rs.

Data-client construction

A data factory is responsible for:

• Validating and interpreting provider configuration.
• Resolving credentials through the provider’s supported boundary.
• Constructing instrument providers and network clients.
• Returning the provider client expected by the data-engine adapter.

DatabentoDataClientFactory constructs the Databento live client path. InteractiveBrokersDataClientFactory constructs the IB data path. Both emit nautilus-model values rather than provider-specific DTOs.

Execution-client construction

InteractiveBrokersExecutionClientFactory constructs the IB execution client. LiveNodeBuilder wraps the returned client in LiveExecutionClient and registers it with ExecutionEngine. Execution reports then update cache, portfolio, and strategy state through the normal engine flow.

Builder registration

A runtime registers factories before calling build. Strategies and execution algorithms are also added to the builder before ownership moves into the node. Factory registration is composition; it does not connect the provider immediately.

The build phase rejects missing or incompatible configuration rather than silently substituting a client.

Shared resources

Factories may share connection state, instrument providers, clocks, cache access, or provider throttling where the adapter explicitly supports it. That sharing remains inside the adapter boundary. Callers should not reach into provider internals or construct partially initialized clients.

Failure behavior

Factory errors occur before the live event loop starts and should include the provider, configuration identity, and failed construction step. Connection and authentication failures occur later during node startup and are bounded by the node’s lifecycle timeouts.

A constructed client is not proof of connectivity. Readiness must observe successful connection, instrument availability, reconciliation, and the node’s running state as applicable.

Extension rule

A new provider should implement the common factory and client contracts only after its need is accepted. This edition demonstrates the pattern through Databento and Interactive Brokers; it does not adopt the other adapter crates.