Ask a trader what could go wrong and you get a list of market scenarios. Ask an engineer and you get a different list entirely: the socket that closed and did not reopen, the token that expired at 12:04, the process that restarted and forgot it was short four lots.
The four that cost the most
The latching feed
A price stops updating but the connection stays open. The strategy keeps computing on a number that is twenty minutes old and takes decisions in a market that has moved. The fix is a quote-age gate: every decision checks the age of the data it is using, and the system halts and alerts rather than trading blind.
The duplicated order
A request times out, the code retries, and the broker has already accepted the first one. Now the position is double. The fix is client-generated order IDs and idempotent submission — the retry carries the same ID, and the broker rejects the duplicate instead of filling it.
The amnesiac restart
The process dies mid-position and comes back believing it is flat. The fix is to persist state before acting, and to reconcile against the broker's book on every start: what do I think I hold, what does the broker say I hold, and stop if they differ.
The runaway
A logic bug turns a signal generator into an order generator. The fix is boring and non-negotiable: an order-rate cap, a daily loss cap, a maximum position, and a kill switch that flattens and refuses to trade again until a human intervenes.
What monitoring must tell you
Not "the server is up". A trading system's health is: heartbeat within the expected interval, quote age below threshold, order rejection rate normal, position matching the broker, and realised loss within the cap. Any one of those breaching should reach your phone before it reaches your P&L.
The runbook test
Write the runbook, then hand it to someone who did not build the system and ask them to restart a strategy safely, mid-session, while holding a position. Whatever they get wrong is the part of your documentation that does not exist yet.
