Strategies Service (during the live execution) or the backtesting engine hosts one or several strategies. Strategies have three inputs:
All states are initialized at startup and are later updated automatically, upon receiving certain events from other components (e.g., a tick from the market data service or an execution report from the account service). All events are processed in a single thread.
When processing an event, the strategy issues orders that are forwarded for execution. When the order status changes or a trade is booked, the strategy will receive the corresponding event.
For the sake of throughput and low latency, strategies cannot request any historical data during the execution. All data must be pre-calculated and kept in one of the states. Strategies Service ensures that the required historical data is hydrated upon startup.
The current version supports only time-aggregated candles (referred to as bars or bar storages) as market data. The next version will add support for ticks and order books.
Upon initialization, strategies must use ClaimBarStorage method to tell Strategies Service that it needs certain candles (usually, defined in the strategy config). AbstractSingleBarHostedStrategy and AbstractMultipleBarsHostedStrategy do this automatically for every bar storage defined in the config. Bar storages and indicators are shared among strategies.
Next, strategies derived from all classes need to call RegisterIndicator to define which indicators they use. Strategies Service then defines how much historical data is required for every bar storage, loads it, and hydrates the candles and indicators.
Every strategy runs on its own subaccount and does not see orders and positions from other strategies (even if several subaccounts run on a single broker account). The account and the strategy states are loaded on startup and later maintained by the Strategies Service. When a strategy callback is called (e.g., OnExecutionReport), the state is already updated.
A strategy state contains two properties: