1
Component boundary
Market data, strategy, risk, orders, and monitoring should expose clear inputs and outputs.
Lesson · Algorithmic and Automated Trading
Trading System Architecture and Components
Define the services, boundaries, data stores, messages, and ownership required to move from market data to an auditable trading decision.
Core concepts
What to understand
Keep the boundaries, state, and authority explicit.
2
State ownership
Each position, order, and strategy state should have one authoritative owner.
3
Failure containment
A component failure should stop or degrade the affected path without corrupting the full system.
Interactive lab
Trading Architecture Lab
Compare a monolith with modular services, inject one component failure, and inspect latency and fault containment.
Trading Architecture Lab
Deterministic synthetic educational data · no broker or live-market connection
SYSTEM MODEL
Process
Design from events and state
Begin with required decisions and authoritative records, not deployment technology.
Map
List market events, signals, risk decisions, orders, fills, and positions.
Assign
Give each state transition one owner and one durable record.
Contain
Define timeouts, circuit breakers, and safe behavior for each dependency failure.
Knowledge check
Check your understanding
Select one answer for each question. Feedback appears immediately, and a wrong choice is answered on its own terms before the rule is restated.
1. Why assign one authoritative owner to order state?
Multiple writers can create contradictory status, quantity, or cancellation decisions.
2. A modular architecture is useful when it:
The value comes from ownership and isolation, not service count.
3. A broker outage should normally cause the system to:
Unknown execution state requires controlled reconciliation, not optimistic assumptions.
4. A modular system has 112 ms of internal hops and the broker takes 160 ms longer to answer during a timeout. What is the end-to-end latency, and which stages are marked bad?
112 + 160 = 272 ms. Modularity does not make the broker answer faster; it decides who else is stuck while it does not.
Practical rules
- Define authoritative state owners.
- Persist decisions before depending on transient messages.
- Design a safe degraded state for every external dependency.
Common mistakes
- Splitting services without defining ownership.
- Using in-memory state as the only order record.
- Treating a network timeout as proof that an order failed.
References
Official reading
These sources cover algorithmic controls, market access, broker APIs, system operations, or security.
FINRA · Regulatory Notice 15-09
Official guidance on supervision, testing, controls, documentation, and monitoring for algorithmic trading strategies.
Alpaca · Working with Orders
Official example of submitting orders and receiving asynchronous order-status updates.