Trading Strategy & Execution Engine.
Engineering case study by Priyansh Dobariya · Python · React · ClickHouse · SQLite
Execution gated by market evidence.
A market-data and trading engine with broker preflight, durable execution state, strategy parity checks, and operator controls.
Behind the build.
Live-execution safety gates
Tick capture and parity review
Order reconciliation
Tools & technologies
What this solves
A backtested strategy can behave differently in live trading when market-feed candles, broker state, or credentials diverge. The engine makes those conditions explicit before an order path opens.
How it works
The Python engine preserves React API and WebSocket contracts and stores execution state in SQLite. ClickHouse remains the analytics and configuration store. A broker adapter handles Dhan orders, while feed processing, strategy logic, tick capture, and reconciliation have separate responsibilities.
From input to outcome
At the strategy boundary, the engine captures feed ticks and refreshes candidate candles from the broker source. Live execution requires an eligible account, broker and market-data preflight, durable leader lease, and explicit live configuration. Orders are reconciled from the broker book; callbacks are deduplicated and checked against engine-owned correlation IDs.
Decisions visible in the code
- Execution-disabled is the default, and live mode requires multiple explicit readiness gates.
- Official candle refresh fails closed when WebSocket-only data would change a backtest-to-live decision.
- Persistent tick capture gives operators material for later parity review.
What the workflow enables
Operators can inspect why an entry did or did not pass the gates and reconcile execution against broker records.
The repository includes runbooks and tests, but this page makes no profitability, live safety, or deployment-success claim.