Quant trading system architecture: a practical blueprint

Cross-post. Original: stellarbytecapital.com/blog/quant-trading-system-architecture

Almost every quant system starts the same way: one script that pulls data, runs a strategy, and places orders. It works — until it doesn't. Add a second strategy, a live account next to the backtest, a third exchange, a teammate, and the single script becomes the bottleneck. The architecture, not the alpha, is now what's holding you back.

Here's the blueprint we use for systems that need to grow: a clean three-tier split that keeps strategies portable, keys safe, and accounts isolated.

The three tiers

1. The control plane (SaaS). The brain. It manages users and auth, stores strategy definitions and parameters, schedules instance lifecycles, and monitors everything. What it deliberately does not do: touch an exchange or hold an exchange API key. It orchestrates; it never trades directly.

2. The execution agent. A lightweight process that runs close to (or on) the trader's own infrastructure. It holds the exchange API keys, maintains the exchange connection, and actually places orders. It connects out to the control plane over a persistent channel (we use WebSocket) to receive assignments and report state — so the keys never leave the agent's environment.

3. The pure strategy. The decision logic, and nothing else. A single pure function — Step() — that takes market state and returns a decision. No network, no database, no clock, no file I/O. It's called identically by a backtest adapter and the live agent, which is what keeps backtest and live honest.

Why split it this way

• API keys are physically isolated. Keys live only on the agent, never in the control plane's database. A breach of the central system exposes zero trading credentials — the single most important property for a multi-user quant platform.
• Strategies are portable. Because the strategy is a pure function with no I/O, the same code runs in backtest, paper, and live without modification.
• Accounts are isolated. Each agent runs its own instances. One account's problem doesn't cascade to others.
• It scales. Add strategies in the control plane; add capacity by adding agents. The tiers scale independently.

The design decisions that make it hold

• Strategy isomorphism. Backtest and live must call the exact same Step() implementation — no if isBacktest branches, ever. This guarantees a backtested edge behaves the same in production.
• Instance lifecycle on a clock. The control plane drives a periodic tick that manages instance state. Strategies don't manage their own timers; time is injected as data.
• Keep the strategy sandbox-clean. No network, no DB, no time.Now() inside the strategy. Side effects — placing orders, logging, persistence — live in the adapters, outside the strategy. This is also what makes strategies safe to optimize automatically.

What to avoid

• The forever-monolith — fine for one strategy; a liability the moment you have two.
• Keys in the central database — the most common and most dangerous shortcut.
• Backtest and live drifting apart — different code paths mean your equity curve tests a strategy you'll never run.
• Strategies that reach out — a strategy that hits the network or reads the clock is non-deterministic and un-backtestable.

Alpha decays. Architecture is what lets you keep finding new alpha without rebuilding the platform each time.

---

We're Xingyao Byte — building quant trading systems, secure AI-execution layers, and payment platforms. Remote, async-first → stellarbytecapital.com