← Back to overview Deep dive · 02

System architecture.

The platform is built as a set of independent, event-driven services, each owning one responsibility and communicating over a message bus. Any one piece can scale, fail, or be replaced without taking down the rest.

The nine services

SVC 01 · GATEWAY

Broker gateway

The single, abstracted interface to every broker. Redundant adapters for Zerodha (primary), Upstox, Angel One, Interactive Brokers, Binance, and MetaTrader sit behind one stable contract.

SVC 02 · DATA

Data engine

Ingests and normalises live market data and macro context into a canonical bar format the rest of the system consumes.

SVC 03 · STRATEGY

Strategy core

Runs the two indicators on closed candles, applies confluence and macro filters, and emits immutable signal objects with entry, three take-profits, stop-loss, tier, and metadata.

SVC 04 · RISK

Risk engine

Position sizing, portfolio and exposure limits, circuit breakers. Every signal in every mode passes through — no bypass exists.

SVC 05 · EXECUTION

Execution engine

Order management, brackets, staged exits, trailing stops, P&L reconciliation to the rupee. A full OMS with a strict order state machine.

SVC 06 · ACCOUNTS

Account manager

Fans one approved signal out across every eligible account in parallel, scaling quantity per account and skipping accounts below minimum viable size.

SVC 07 · CONTROL

Dashboard API

FastAPI control plane. WebSocket streaming for live views. Sensitive actions gated by RBAC and 2FA. Config changes take effect immediately.

SVC 08 · ANALYTICS

Analytics · continuous improvement

Weekly performance job, A/B testing across accounts, loss-cluster feedback loop that promotes approved rules into the risk engine after human review.

SVC 09 · PLUGINS

Plugin host

The extension point. New strategy modules load into a sandbox, run in shadow mode for a period, and only influence live trading after review.

The trade path, in text

The lifecycle is deterministic — the same candles and configuration always produce the same result.

MARKET DATA Data engine · normalise
Strategy core · MASTER + CDV PRO on closed candles
confluence graded, tier assigned
macro-bias + volatility-regime filter
immutable signal object emitted
Risk engine · sizing + limits + circuit breakers
Account manager · fan-out, quantity scaled per capital
Execution engine · bracket order + staged exits
reconciled P&L per account and consolidated
at any point: Kill switch flattens all, halts all, awaits human restart.

The data plane

Why event-driven

Because trading is inherently asynchronous. Data arrives when it arrives. Fills come back on the broker's schedule. Kill-switch triggers can come from Telegram at 2 a.m. Wiring services together with events instead of direct calls means any consumer can drop, be redeployed, or scale independently without stalling the pipeline — the events sit in the bus until someone reads them.

It also gives us free replay. Rebuilding the state of the system at any point is a matter of replaying the event log from a checkpoint. This is what lets the analytics service run counterfactuals and shadow-mode plugins score against the same events as production.

Configuration over code

Every strategy parameter, risk limit, and account setting lives in the database, not hardcoded. Adding a broker account, changing a risk limit, or deploying a new strategy version is a data change — not a code change and redeploy.

The stack, in one paragraph

Python across the backend services with FastAPI for the control-plane API; PostgreSQL with the TimescaleDB extension for time-series data; Redis for shared state; Kafka for the event stream; React, TypeScript, and Tailwind for the dashboard; Docker for packaging. Secrets are held in a managed secret store (never in code or the database), access is role-controlled, and sensitive actions require a second factor.

What runs where — path to production

The remaining work is not building — it's deployment. A lean single-region setup to start: one Kubernetes cluster, one Postgres/Timescale instance with hot-standby, a managed Redis, and a Kafka cluster sized for current throughput with headroom. Real broker credentials in the secret store. Live market-data feeds wired to the data engine. Then live-connect drills, a fresh kill-switch drill, a confirmed go/no-go — and only then, small live capital in semi-automatic on one account, one asset class.

← BACK
Signal engine
HOME →
Product overview