Case Study · Systematic Trading Infrastructure
Quantfund:
the infrastructure a trading engine runs on
Scope boundary
This case study describes the infrastructure I built. The trading strategy is operated by the client. No P&L figures, live trading results, or performance claims are included here. All claims are about the engineering infrastructure. Test coverage, deployment architecture, and safety system wiring.
A systematic trading system is not a strategy. It's a machine. If the machine has silent failures, no kill switch, and unmonitored state, the strategy is irrelevant. What I built is the machine.
The problem with most trading engines
Every trading engine I've audited has the same bug. The kill switch exists in the code, but it doesn't actually stop a runaway strategy under load. It's a manual process, not a deterministic halt. State doesn't persist correctly, so a restart after an incident reads a stale position. Logs aren't chained, so you can't reconstruct what happened in the 200ms before the loss. Tested in staging. Fails in production. That's what I fixed here.
The mandate was to build an engine where every safety layer is wired, tested, and deterministic. Before the strategy runs on it.
The build
The engine is a Python stack running under uv, with a layered safety architecture below the strategy. From the bottom up: a SQLite halts store (tamper-evident, WAL mode), a heartbeat monitor, a kill switch that propagates through SIGTERM drain, a circuit breaker with configurable reset windows, and a halt state machine that manages transitions.
Each layer is independently testable. The circuit breaker tests don't require a live exchange connection. The halt state tests run with synthetic events. 1,000+ test functions across 97 test files. Covering the safety package, execution layer, data pipeline, metrics, and API.
The shadow mode pipeline runs the full orchestration loop against live market data without placing orders. By day 83 of the shadow run on the production droplet, state was persisting correctly across restarts, signals were logging to the volume, and the Telegram alerter was firing on every circuit breaker event.
Safety systems in detail
Kill switch
6-layer halt architecture. SIGTERM drain: orchestrator → API → NATS → halts store. No order in flight when the system stops.
Circuit breaker
Configurable drawdown threshold, consecutive loss limit, Sharpe floor. Auto-pause after N resets in 24 hours. Audit event on every trigger.
Heartbeat monitor
Detects stale state, missed iterations, and dead orchestrator loop. Triggers halt if missed threshold exceeded.
SHA-256 journal
Daily markdown journal with hash chain. Every entry references the previous hash. Tamper-evident reconstruction of any session.
Telegram alerts
RED/YELLOW/fill/kill-switch/config-change notifications. Fires on circuit breaker trips, position fills, kill-switch invocations.
Pre-trade validation
Daily loss tracking, position limit enforcement, NaN/Inf rejection at the signal boundary. Bad data cannot reach the order management system.
Outcomes (engineering metrics only)
What this means for a client
If you're building a trading system, the hardest part isn't the strategy. It's the infrastructure that makes the strategy safe to run in production. Kill switches that actually work under load. Circuit breakers that are wired into the execution loop. Logs you can trust after an incident.
I've built this once. The patterns are proven. What I bring to your engagement is an engineer who knows exactly where systematic trading infrastructure fails and has already fixed those failure modes in a live system.
If your trading infra leaks alpha