01.The four parts
Keeping these separate makes the bot testable, which matters more than it sounds — a strategy you cannot test against recorded data is a strategy you are testing with real money.
- Data layer: websocket feed maintaining a local order book, seeded from a REST snapshot.
- Strategy layer: pure logic turning market state into intended positions. No network calls here.
- Execution layer: places and cancels orders, handles partial fills and retries.
- Safety layer: position limits, stale-data detection, and a kill switch that actually works.
02.Stale data is the failure that costs money
A dropped websocket that reconnects silently, or a feed that hangs while the socket still looks open, leaves your bot trading against a book that stopped updating. It will keep placing orders confidently into a market that has moved. Treat data age as a first-class input: if the last update is older than a threshold you set, stop trading and say so.
- Track the age of your last update and refuse to act on stale state.
- Use heartbeats; a hung socket looks identical to a quiet market.
- On reconnect, discard local state and reseed from a snapshot rather than merging.
03.Cancellation matters more than speed
Most beginner bots optimise how fast they can place orders. The dangerous gap is orders you cannot pull. If your bot posts a quote and then loses the ability to cancel it, that quote sits there for informed traders to pick off while your view of the world is out of date. Verify cancellation works, and know what your bot does when it fails.
- Confirm cancellations rather than assuming they succeeded.
- Know your maximum exposure if every resting order filled right now.
- A bot that cannot cancel should not be quoting.
04.Safety rails that are not optional
Every one of these exists because someone lost money without it. They are cheap to add up front and painful to retrofit after an incident.
- A hard per-market position cap, enforced in code, not in intention.
- A global exposure cap across correlated markets, not just per market.
- A kill switch you can hit from outside the process.
- A dry-run mode that logs intended orders without sending them.
- Alerts on repeated errors, rate limits and resyncs.
05.Test against recorded data first
Run the strategy against recorded market data before it touches live orders, then in dry-run against the live feed, and only then with real capital at a size where being wrong is affordable. Skipping the middle step is how bots that backtest beautifully discover they mishandle partial fills.
- Backtest on recorded data, accounting for the fees and slippage you will actually pay.
- Dry-run live: real feed, real decisions, no orders sent.
- Go live small, and treat the first weeks as continued testing.