Drill: trading systems

Filled. At the exchange the order traded before the cancel arrived, so the cancel was rejected as too late. Our system must have kept the order as pending cancel, still counting its open quantity for risk, applied the fill to the position and P&L when it arrived, and then closed the order as filled on the reject.

The general rule is that the trading system's view lags the exchange's, so pending requests are treated pessimistically and every incoming event is applied whatever we have asked for.

I would design for the operations: adds, deletes and executions identified by order id, most of them near the top of the book. Orders live in a preallocated pool; an open-addressing hash map goes from exchange id to pool handle. Each side keeps levels in an array indexed by ticks from a reference price, with an overflow for far prices, and each level holds its total quantity and an intrusive time-ordered queue linked through the orders.

Every operation is then a hash lookup and a few array accesses with no allocation, and I track the best level index so top of book is immediate. Prices are integer ticks, never doubles.

While the order has quantity left and the best ask is at or below its limit, take the best ask level and trade against its resting orders in arrival order, each trade at the resting order's price for the smaller of the two quantities, removing resting orders as they fill and the level when it empties. When the loop stops, a day order rests its remainder on the bid side at its limit; an IOC cancels it.

Around that core, a real engine adds sequencing for a single defined order of events, journaling, self-trade prevention, price bands and publication of every change.

Price collars against a reference, maximum quantity and notional per order, position limits counting open orders, exposure limits, order-rate limits including the exchange's, duplicate and runaway detection, and a kill switch that stops new orders and cancels open ones.

For speed, limits and positions sit in flat arrays indexed by the dense instrument id, positions are updated incrementally on every order and fill, arithmetic is integer ticks and lots, rate limits are fixed-size token buckets, and limit changes arrive by atomic swap of an immutable table. The passing path is a handful of compares.

The foundation is deterministic replay: recorded packets with their receive timestamps fed through the same feed handler, book and strategy code as production, with time taken from the data and no dependence on thread timing, so the same recording always gives the same decisions. That lets us test every change against long periods of history and reproduce any production incident exactly.

Around it, unit tests for components, especially order-state edge cases like fills crossing cancels; simulated exchange responses for rejects and disconnects; and finally a cautious live start with tight risk limits.