Runtime Model
Purpose
This section describes how the System operates during Runtime.
While the Architecture and Stacks sections define the structural organization of the System, the Runtime section explains how these components behave when the System is actively running.
The Runtime model describes:
- event-driven processing
- operational System behavior
- monitoring and failure handling
Together these documents explain how the System behaves in both Backtesting and Live Runtimes.
Runtimes
The System operates in two primary Runtimes:
Research Runtime
This Runtime executes the System in a simulated Runtime.
Strategies are evaluated using historical datasets while interacting with a simulated Venue.
The Research Runtime enables:
- deterministic replay of historical market Events
- Strategy experimentation
- evaluation of trading performance
This Runtime is primarily operated by the Backtesting Stack.
Live Runtime
The live Runtime operates the System against real Venues.
The System consumes real-time market data and executes trading actions through Venue adapters.
The live Runtime is responsible for:
- real-time Strategy execution
- risk enforcement
- Order execution
- continuous system monitoring
This Runtime is operated by the Execution Stack.
Trading Runtime Model
Both Runtimes execute the same event-driven trading core.
The System processes Events sequentially and updates internal States based on those Events.
The Runtime model follows a deterministic Event processing pipeline:
Market Event
↓
State Update
↓
Strategy Decision
↓
Risk Validation
↓
Outbound Queue
↓
Execution
Execution responses generated by Venues produce new Events that feed back into the System.
Event Processing Loop
At Runtime the System operates as a continuous event-processing loop.
Market Event
↓
State Update
↓
Strategy Evaluation
↓
Trading Intent
↓
Risk Validation
↓
Outbound Queue
↓
Venue Adapter
↓
Venue
↓
Execution Events
↓
State Update
Market Events and execution Events continuously update States and drive trading decisions.
This event-driven feedback loop ensures consistent System behavior across both Backtesting and Live Runtimes.
Runtime Components
The Trading Runtime consists of several cooperating components.
State Management
Maintains the internal State derived from processed Events.
Strategy Layer
Evaluates trading opportunities based on current State.
Risk Engine
Validates trading Intents before they reach execution.
Queue
Regulates outbound execution requests and enforces sequencing constraints.
Venue Adapters
Translate internal execution requests into Venue-specific API interactions.
Operational Concerns
Operating a trading system requires additional Runtime capabilities beyond the core trading loop.
These include:
- monitoring and observability
- incident detection
- failure handling
- system recovery
The following documents describe these operational concerns in detail:
- Monitoring
- Incident Model
- Recovery Model
Relationship to Stacks
The Runtime model operates on top of the System Stacks described in the Stacks section.
Different Stacks are responsible for different Runtimes.
| Stack | Research Runtime | Live Runtime |
|---|---|---|
| Backtesting | active | inactive |
| Execution | inactive | active |
| Analysis & Observability | active | active |
The Runtime documentation focuses on how these Stacks behave when the System is actively running.
Runtime Documentation
Additional documents in this section describe operational aspects of the System Runtime.
These include:
- monitoring infrastructure
- incident handling
- system recovery procedures
- specific Runtime behavior