Principle:Nautechsystems Nautilus trader Order Creation
| Field | Value |
|---|---|
| sources | https://github.com/nautechsystems/nautilus_trader , https://nautilustrader.io/docs/ |
| domains | algorithmic trading, order management, order types, order factory pattern |
| last_updated | 2026-02-10 12:00 GMT |
Overview
Order creation defines the systematic construction of properly initialized order objects through a factory pattern, ensuring that all orders carry correct identifiers, timestamps, and parameters before submission to the execution engine.
Description
In algorithmic trading, orders are the primary mechanism through which strategies interact with the market. Creating orders correctly is critical because:
- Identity management: Each order must have a unique client order ID that associates it with the originating strategy and trader. Duplicate or malformed IDs cause execution engine failures.
- Parameter validation: Order parameters (quantity, price, time-in-force, trigger type) must be validated at creation time, not at submission time. Early validation prevents invalid orders from entering the execution pipeline.
- Type safety: Different order types (market, limit, stop-market, stop-limit, trailing stop, bracket) have different required and optional parameters. A factory method for each type ensures that the correct parameters are provided.
- Timestamp consistency: Orders must be timestamped at creation using the strategy's clock, which may be a simulated clock during backtesting. The factory uses the correct clock reference.
The Order Factory Pattern addresses these concerns by providing dedicated creation methods for each order type. Instead of constructing order objects directly (which requires providing many parameters including internal identifiers), the strategy calls factory methods that handle ID generation, timestamp assignment, and parameter defaulting.
Supported order types:
- Market order: Executes immediately at the best available price. Simplest order type with highest fill probability.
- Limit order: Executes at a specified price or better. Used for precise entry/exit at desired price levels.
- Stop-market order: Triggers a market order when the market price reaches a specified trigger price. Used for stop-losses and breakout entries.
- Stop-limit order: Triggers a limit order when the market price reaches a trigger price. Combines stop protection with price control.
- Trailing stop orders: Stop orders where the trigger price trails the market price by a fixed offset or percentage.
- Bracket orders (order lists): Coordinated sets of orders (entry + stop-loss + take-profit) that are managed as a unit.
Usage
Apply the order creation pattern when:
- A strategy needs to submit any type of order to the market.
- You want automatic client order ID generation tied to the strategy identity.
- You need consistent timestamping across backtest and live environments.
- You are building strategies that use multiple order types (e.g., limit entries with stop-loss protection).
Theoretical Basis
Order creation applies the Factory Method Pattern:
PATTERN: Factory Method
PARTICIPANTS:
OrderFactory -- The creator (provides factory methods for each order type)
Order -- The abstract product (base order class)
MarketOrder -- Concrete product
LimitOrder -- Concrete product
StopMarketOrder -- Concrete product
FLOW:
1. Strategy calls order_factory.market(instrument_id, side, quantity)
2. Factory generates a unique client_order_id
3. Factory stamps the order with the current clock timestamp
4. Factory validates all parameters
5. Factory constructs and returns the typed order object
6. Strategy submits the order via submit_order(order)
Why a factory instead of direct construction?
Direct construction of order objects requires providing:
trader_id,strategy_id(identity context)client_order_id(unique identifier -- requires a generator)init_id(UUID for the initialization event)ts_init(timestamp from the correct clock)contingency_type,order_list_id,linked_order_ids,parent_order_id(contingency context)exec_algorithm_id,exec_algorithm_params,exec_spawn_id(execution algorithm context)
The factory encapsulates all of this, exposing only the parameters the strategy author needs to decide: what instrument, which direction, how much, and at what price.
Pseudocode:
CLASS OrderFactory:
FIELD trader_id, strategy_id, clock, id_generator
FUNCTION market(instrument_id, side, quantity, **options) -> MarketOrder:
client_order_id = id_generator.next()
RETURN MarketOrder(
trader_id = self.trader_id,
strategy_id = self.strategy_id,
instrument_id = instrument_id,
client_order_id = client_order_id,
order_side = side,
quantity = quantity,
ts_init = clock.timestamp_ns(),
...options
)
FUNCTION limit(instrument_id, side, quantity, price, **options) -> LimitOrder:
client_order_id = id_generator.next()
RETURN LimitOrder(
...same identity fields...,
price = price,
...options
)
FUNCTION stop_market(instrument_id, side, quantity, trigger_price, **options) -> StopMarketOrder:
...similar pattern...
Key invariant: Every order created through the factory is guaranteed to have a unique client_order_id, a valid timestamp from the strategy's clock, and the correct trader_id/strategy_id association.