From Edge to Execution
You have validated edges. You have position sizing rules. You have risk budgets. Now comes the question every systematic trader eventually faces: how do you turn these rules into code that executes trades while you sleep?
This lesson breaks down the architecture of a trading bot - not the specific code, but the conceptual building blocks you need to understand before writing a single line.
The Four Core Components
Every trading bot, regardless of complexity, needs these four components:
1. Data Ingestion - Getting market data into your system. This includes price feeds, order book data, and whatever alternative data your edges require.
2. Signal Generation - The logic that decides when to trade. Your edges live here, implemented as code that processes incoming data and outputs trading decisions.
3. Order Execution - Translating signals into actual exchange orders. This includes position sizing, order type selection, and handling exchange responses.
4. State Management - Keeping track of positions, pending orders, and system health. The source of truth for what your bot owns and owes.
Data Ingestion Architecture
Data comes in two flavors: historical and real-time.
Historical Data is used for backtesting and calculating indicators that need lookback periods. You typically store this in files (Parquet, CSV) or databases (PostgreSQL, MongoDB).
Real-Time Data streams in continuously during trading. This usually comes via WebSocket connections to exchanges.
The architecture pattern we recommend: Exchange WebSocket feeds into a Message Queue (Redis), which feeds both a Data Processor for signal generation and Historical Storage for persistence. The message queue decouples data arrival from processing - if your signal generator is slow, messages buffer instead of dropping.
Signal Generation Architecture
This is where your edges become code. The signal generator takes in data and outputs trading decisions.
Single-Threaded Approach: Process data sequentially. Simple to implement and debug. Works fine if your signals don't require extreme speed.
Event-Driven Approach: React to market events (new candle, price threshold, indicator trigger). More complex but handles multiple edges efficiently.
Scheduled Approach: Run on fixed intervals (every minute, every 5 minutes). Predictable and easy to monitor.
We strongly recommend loose coupling between signal generation and execution. A bug in execution shouldn't stop you from generating signals, and vice versa.
Order Execution Architecture
This component interfaces with exchanges. It's where most bugs cause real money loss.
Orders go through states: pending, submitted, partial, filled, cancelled. Your execution engine must track these states and handle transitions.
Critical: Never assume an order worked just because you didn't get an error. Always verify fills independently.
State Management Architecture
State management is the unglamorous part that prevents disasters.
What State to Track: Current positions, open orders, account balances, system health.
Source of Truth: Your local state will diverge from exchange state. We recommend local state with periodic sync - reconciliation on startup, after errors, and on a scheduled interval.
Persistence: Your state must survive restarts. Use a database for critical state.
Key Architectural Principles
1. Separation of Concerns - Each component does one thing.
2. Fault Isolation - Failures in one component don't cascade.
3. Observability - Every component logs its actions.
4. Graceful Degradation - When things go wrong, fail safely.
5. Configuration Over Code - Edge parameters, position sizes, and risk limits should be configurable without code changes.
Common Architectural Mistakes
Mistake 1: Monolithic Design - Everything in one script. When something breaks, everything breaks.
Mistake 2: No Persistence - State lives only in memory. Restart loses all position knowledge.
Mistake 3: Synchronous Everything - Waiting for each exchange call blocks everything else.
Mistake 4: Trusting Local State - Assuming your position tracking is always correct.
Mistake 5: No Kill Switch - No way to stop trading instantly.
Takeaway
Building a trading bot isn't just about coding your strategy. It's about architecting a resilient system that can handle failures, maintain accurate state, and execute reliably.
The architecture decisions you make now will determine how many 3 AM emergencies you'll face later.