Our order manager occasionally raised KeyError: unknown order when a fill event arrived on the websocket before the REST place-order call returned. It keyed orders by exchange order id, which it only learned from the REST response. Keying by client order id and buffering unknown events fixed it.
Our quoting bot stayed far below request weight limits and still got -1015 Too many new orders at the worst moments. Order placement has its own per-account count limits, and our cancel-and-replace loop doubled order churn when prices moved fast. An order rate limiter and order amendment fixed it.
Most trading bot failures we have seen are not strategy bugs; they are state bugs: lost fills, duplicate orders, wrong positions after a restart. This guide describes an architecture that keeps state correct: separated components, an order state machine, persistence, risk checks and reconciliation.
During a volatile minute, our place-order request timed out and the bot retried. Both requests reached the exchange, and we held twice the intended position. A timeout does not mean the order failed. Client order ids, query-before-retry and an unknown state fixed it.