How to Build a Trading Bot: A Practical Walkthrough

Structuring the system

data/          fetch, validate, cache market data
strategy/      pure functions: (data, state) -> desired positions
risk/          validate and size every order; veto authority
execution/     broker interface: place, amend, cancel, poll fills
state/         persistent record of positions, orders, equity
monitor/       heartbeat, alerts, reconciliation
config/        parameters, limits, credentials (never in code)
logs/          structured, append-only, every decision recorded

Key design rule:
   strategy/ must be a PURE function.
   Same inputs -> same outputs, no side effects,
   no network calls, no clock reads.

This is what makes it testable, backtestable, and
debuggable when something goes wrong at 3am.

The purity rule is the most valuable single design decision. A strategy function that reads the clock or calls an API cannot be tested deterministically, cannot be backtested on the same code path, and cannot be reasoned about when it misbehaves.

The main loop

while running:
    1.  fetch market data
    2.  validate: is it fresh, complete, sane?
        if not -> alert, skip this cycle, do not trade
    3.  reconcile: does broker state match our state?
        if not -> alert, halt, require human review
    4.  compute desired positions from strategy(data, state)
    5.  compute the difference from current positions
    6.  for each required order:
            risk layer validates or vetoes
            execution places with a unique client order ID
    7.  poll for fills, update state, persist to disk
    8.  place or amend protective stops immediately
    9.  log everything
   10.  emit heartbeat
        sleep until the next cycle

Every step between 2 and 9 can fail.
Each failure needs a defined response, and the default
response is always: stop trading and alert a human.

State management, the hardest part

• Persist after every change. The process will be restarted, by you, by a crash, or by the host. It must resume knowing exactly what it holds and what orders are outstanding.
• Treat the broker as the source of truth. Your record is a cache. Reconcile against the broker on startup and on a schedule, and halt on any mismatch.
• Handle partial fills explicitly. A position of 37 shares when the strategy expected 100 must propagate correctly through every subsequent calculation.
• Track orders through their full lifecycle. An order you believe is cancelled but that actually filled is the source of the worst state bugs.
• Use append-only logs. You will need to reconstruct what the system believed at a specific moment, and overwritten state makes that impossible.
• Make restarts safe. Restarting mid-cycle should never duplicate an order or lose a stop. Test this deliberately by killing the process at random points.

Failure modes and responses

Testing before real money

1. 1

   Unit test the strategy function

   Feed it known data and assert the expected desired positions. Because it is pure, this is straightforward and fast.

2. 2

   Backtest through the same code path

   Swap the data source and broker interface for historical versions. If backtest and live use different logic, you are testing something other than what you will run.

3. 3

   Test failure injection

   Deliberately simulate timeouts, partial fills, rejections, stale data, and crashes. Confirm each produces the correct response rather than an exception.

4. 4

   Run in paper mode for weeks

   Verify signal counts, order flow, and state handling. Compare against what the backtest would have done on the same days.

5. 5

   Run live at minimum size

   Real fills, real rejections, real latency. Watch every cycle. Expect to find bugs that paper trading did not surface.

6. 6

   Add monitoring before scaling

   Heartbeat, alerts, and reconciliation must be working before size increases, not after the first incident.