Systems Architecture
The Architecture of an Automated Trading System
The six subsystems between a strategy definition and a filled order, what each is responsible for, and where the hard failure modes live.
3 min read
All topics
Topic
Trading System Architecture
The engineering beneath automated trading: data pipelines, order management, reconciliation, risk gates and monitoring.
Definition
- What is trading system architecture?
- A trading system architecture is the set of subsystems that carry a strategy definition through to a filled order, market data, strategy evaluation, a risk gate, order management, position reconciliation and monitoring. Each with a distinct failure mode.
4 pieces published on this topic · Updated
Understanding trading system architecture
The interesting engineering in an automated trading system is not the strategy logic. Strategy code is usually short. The difficulty lives in the subsystems around it: normalising market data, deciding whether an order is permitted, submitting it safely, and reconciling what you believe you hold against what the broker says you hold.
The organising principle is that each subsystem owns exactly one thing and can be reasoned about alone. Market data owns time, so nothing downstream invents a timestamp. Strategy evaluation owns nothing. It is a pure function, which is the only way a backtest and a live system can run the same code. A separate risk gate owns the veto, so a strategy bug cannot place an order no rule would have allowed.
Almost every hard bug in this domain is a partial-failure bug. A network call that succeeds at the broker and fails on the way back. A fill that arrives for half the quantity. An authorisation that expires between entry and exit. A system that has not been designed for these does not fail loudly; it drifts out of agreement with reality and keeps trading.
Common questions
- Why must strategy code be free of side effects?
- So that backtesting and live trading exercise the same program. If strategy code reads the clock or calls the broker directly, the backtest is testing something other than what will trade, and the difference between them is untestable automatically.
- What is reconciliation, and why does it matter so much?
- Reconciliation is asking the broker what you actually hold and treating that answer as authoritative rather than trusting a local record assembled from API responses. It matters because responses get lost, and a system confidently wrong about its own positions will size the next trade on a fiction.
- Which failure should a trading system be most careful about?
- Being able to enter positions while unable to exit them. Every other failure is recoverable; that one accumulates risk with no way to shed it. A system that detects a broken exit path should refuse new entries immediately. This is the case that must fail closed.
Technical articles
Engineering deep-dives covering this topic.
Systems Architecture
How a Backtesting Engine Works: Event Loop, Fills and Costs
Inside a backtest: the event loop, how fills are simulated, why lookahead bias appears, and what separates a useful engine from a plausible one.
3 min read
Compliance & Regulation
What a Five-Year Order Audit Trail Has to Contain
The retention obligation, the fields an inspection actually asks for, and why "comprehensive logging" is not an answer to the question.
4 min read
Compliance & Regulation
Static IP, API Keys and the Once-a-Week Rule
How authorised API access works under the framework, and why the once-per-calendar-week limit on changing an IP breaks naive failover designs.
3 min read
Related topics
Put this into practice
Describe a strategy in plain language, backtest it against historical data, and paper trade it before any capital is committed.