Understanding the Architecture of Multi-Leg Strategy Execution and State Management #4409
Unanswered
mohitmathur-ms
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
1. How is a multi-leg strategy structured internally?
I'm trying to understand the overall architecture of a multi-leg strategy.
1. Does a Strategy Actor own multiple Leg objects?
2. Are legs independent state machines?
3. How do strategies and legs interact during execution?
I'm looking for the high-level design rather than implementation details.
2. How does the execution flow work for a strategy and its legs?
Once a market event (tick/bar/order update) arrives, what is the typical execution flow?
1. How are multiple legs evaluated?
2. How are conditions such as Stop Loss, Target, and Trailing Stop processed?
3. How are actions (entry, exit, modify, re-entry) generated and executed while keeping the execution deterministic?
3. How is runtime state managed and recovered after a restart or disconnect?
How does the framework maintain and recover the runtime state of active strategies?
1. What state is kept in memory vs persisted (e.g., Redis)?
2. After a restart or broker disconnection, how are orders, trades, positions, and strategy state synchronized so execution resumes correctly without duplicate actions?
All reactions