Principle:Nautechsystems Nautilus trader Client Factory Registration

Field	Value
sources	https://github.com/nautechsystems/nautilus_trader, https://nautilustrader.io/docs/
domains	algorithmic trading, design patterns, factory pattern, plugin architecture
last_updated	2026-02-10 12:00 GMT

Overview

Client factory registration is the application of the Abstract Factory pattern to trading system architecture, enabling exchange-specific data and execution clients to be created through a uniform interface without the trading node needing compile-time knowledge of any particular exchange implementation.

Description

A live trading platform must support multiple exchanges, each with a radically different API surface. If the node directly instantiated exchange clients, every new exchange would require modifying the node itself -- violating the Open/Closed Principle. The Client Factory Registration principle solves this with a two-step pattern:

1. Define abstract factory interfaces -- LiveDataClientFactory and LiveExecClientFactory -- each declaring a single static create() method that accepts a standard set of infrastructure objects (event loop, message bus, cache, clock) plus a configuration.
2. Register concrete factories on the node before the build phase. Each exchange adapter ships its own factory subclass (e.g., BinanceLiveDataClientFactory) that knows how to construct the exchange-specific client from the provided config.

At build time, the node iterates over its data_clients and exec_clients configuration dictionaries, matches each entry to the registered factory by name, and calls factory.create(). This decouples the node from any exchange-specific import, making the system extensible through plugin-like registration rather than code modification.

Usage

Apply this principle whenever:

• A new exchange adapter is being added to the platform.
• The operator wants to run multiple exchanges simultaneously within a single node.
• Third-party or proprietary exchange integrations need to be injected without modifying the core library.

Theoretical Basis

Abstract Factory Pattern

The Abstract Factory pattern provides an interface for creating families of related objects. In a trading system, the "family" is the pair of data client + execution client for a given exchange:

AbstractFactory
  +-- create(loop, name, config, msgbus, cache, clock) -> Client

ConcreteFactory (e.g., BinanceLiveDataClientFactory)
  +-- create(...) -> BinanceDataClient

The node holds a mapping of name -> factory_class and invokes the factory at build time.

Registration Before Build

The lifecycle enforces a strict ordering:

1. Construct TradingNode(config)
2. Register factories:
     node.add_data_client_factory("BINANCE", BinanceLiveDataClientFactory)
     node.add_exec_client_factory("BINANCE", BinanceLiveExecClientFactory)
3. Build:
     node.build()   -- factories are invoked here
4. Run:
     node.run()

Attempting to build without registering factories for configured clients will result in a runtime error, enforcing correctness.

Inversion of Control

By registering factories rather than clients, the node achieves inversion of control: it does not know how to create a Binance client; it only knows when to ask the factory to do so. This allows the exchange adapter to own all venue-specific logic (endpoint resolution, authentication, WebSocket management) while the node remains exchange-agnostic.

Name-Based Dispatch

Each factory is registered with a string name (e.g., "BINANCE") that must match the key used in the data_clients / exec_clients config dictionaries. This name-based dispatch provides a simple, explicit, and debuggable binding mechanism without requiring a service locator or DI container.

Related Pages

• Implementation:Nautechsystems_Nautilus_trader_TradingNode_Add_Client_Factory