Live Trading: Routing, Startup, Recovery, and Shutdown Behavior
Summary
This guide explains how a live trading node differs from a backtest even when both use the same strategy and execution code. Live operation adds venue-specific rules, network uncertainty, interleaved event timing, persistence behavior, external orders, and reconciliation with venue reports. It also covers routing commands among execution clients, including explicit venue and fallback routes, and warns that multiple clients for one venue do not by themselves isolate account positions and order management.
The guide lays out the node lifecycle: restore cached state, connect data and execution clients, optionally reconcile venue state, start trader components, run checks, and coordinate shutdown. It describes how unresolved submissions are handled at shutdown, how Python can host a node on an existing event loop, and how shutdown-on-error works. These are operational behaviors and API contracts, not evidence of trading performance. Venue adapters and transport failures affect outcomes; acknowledgement of submission does not confirm later cancellation or a flat position. Startup and shutdown queue drains can also delay a host event loop, and the documented runtime permits only one concurrent live node per process.
Key ideas
- Live systems add venue, transport, timing, persistence, and reconciliation concerns that backtests may not reproduce.
- Execution commands select clients through client IDs, account routing, venue routes, or a default client.
- Startup can restore cached state and reconcile local execution state with venue reports before strategies begin.
- Shutdown may report unresolved submissions even after clients disconnect and the kernel stops.
- Python can host a live node on an existing event loop, with lifecycle supervision and disposal after the run completes.
Tags
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.