I wrote this order book matching engine in Go primarily as an exercise. It is single-threaded, uses no pointers, and performs no memory allocations in its critical paths. Orders and price levels are stored in flat arrays and linked via indices rather than references (indexed list instead linked list), which ensures that the garbage collector does not interact with the order book. Adding, canceling, or executing an order takes only a few nanoseconds.

An order id is a specific code containing both a slot index and a sequence number. This allows for extremely fast, constant-time order cancellation without the need for hash tables. Furthermore, old or previously canceled orders are effectively locked out.

The project consists of three modules. The first, levels, maintains queues of orders for each price level, tracking both price and volume. The second, book, organizes these levels by price for both buyers and sellers. The third, matching, handles the execution of limit orders, supporting GTC, IOC, FOK, and PostOnly order types. All modules have been thoroughly tested, including the use of randomized data to verify correctness against a reference model. The repository includes a benchmark comparing these queues to standard implementations based on container/list; the results show that adding and canceling orders is approximately 10 times faster. With one million active orders, performance is 8 times higher—all achieved without a single memory allocation.

The price index is implemented as a two-tier structure. Price levels are stored in blocks of 128 entries each, with a short chain of keys pointing to these blocks. In essence, this is a two-level B+ tree—a configuration sufficient for the order book of a single instrument. Both tiers consist of standard arrays without pointers. Searches begin at the best price and proceed deeper into the book; consequently, a search near the spread affects only one block, and adding an order deeper in the book requires modifying at most one block. Compared to a standard sorted array, this approach increases overhead by 1–3% during the most active operations, but it delivers significant performance gains: it is 2 times faster when modifying 1,000 levels deep in the book, 12 times faster at 10,000 levels, and 59 times faster at 50,000 levels. A benchmark comparing this structure to a simple array can be found in the book directory. Red-black trees (from emirpasic/gods) and B-trees (from google/btree) perform worse in these scenarios—they are 3–5 times slower near the spread and 10 times slower when traversing deeper levels. Furthermore, they underperform the block-based structure even during active trading and require separate memory allocation for each node. These specific measurements are not included in the repository to avoid adding unnecessary dependencies for testing.