What this is
The live execution half of a two-project trading stack. The companion project is the ML Trading Pipeline, which handles offline research and backtesting; this one handles real-time market data and live trade execution. Strategies validated in the pipeline get deployed here.
Architecture
Event-driven and loosely coupled by design, so strategies, market data, and execution can be developed and deployed independently.
- Gateway service. Holds the Alpaca WebSocket connection. Translates incoming ticks into CloudEvents-compliant messages and publishes them to the bus.
- NATS JetStream bus. Durable, persistent event stream so a strategy service that reconnects can replay events it missed without duplicating execution.
- Strategy services. Each strategy is its own service that subscribes to the data stream, evaluates rules, and publishes signal events. New strategies can be added without touching the rest of the system.
- Backtesting harness. A historical simulation mode that replays archived events into the same services, so the production code path is the only code path. No "paper trading" branch that drifts from live.
- Strategy profiles. Each strategy can run with multiple parameterisations (risk/reward, position sizing, drawdown limits) for A/B comparison without redeploying.
Why event-driven
The naive shape for a trading bot is a single process polling a REST endpoint. That breaks the moment you want a second strategy, a second market, or any kind of audit trail. Event-driven from day one means the same architecture handles 1 strategy or 50, and any post-trade analysis is just another consumer subscribing to the same event log.
Stack
Python, Alpaca API (WebSocket + REST), NATS JetStream, CloudEvents, Pandas, asyncio, Docker.
