C++ Trading Exchange

An exchange that allocates on the hot path will stall when the market does not. I am building a C++ trading exchange in the Build Fellowship. So far the piece in the tree is a fixed-size memory pool.

The problem

The matching engine, the order server, and the market-data feed still have to ask for memory. If they ask the heap on the path that handles an order, the allocator becomes part of the latency, and it becomes part of it at the moment you least want a surprise. The person it frustrates is the one trying to reason about a match when the cost of the match includes a malloc.

The pool is the first piece, not the exchange. A fixed block of slots you can take and return, without asking the heap each time, is the part I can point at today.

How I built it

MemPool<T> fills a vector of slots and marks every one free at the start. The size is fixed when the pool is built. allocate() placement-news a T into a free slot, so the object is constructed in storage the pool already owns. Returning a slot marks it free again. There is no second heap trip hiding in the allocate path.

The tests cover that pool: take a slot, build a T in it, give it back, take it again. The project is C++ and Bazel. Bazel is how the pool and its tests are the target, rather than a file that happens to compile on my machine.

I am not describing a matching engine I have not put in the tree. The order server and the market-data feed are the reason the pool exists. They are not, yet, the code next to it.

Challenges and what I learned

The pool is not an exchange. It can hand back a slot, and the matcher that would use it is still the rest of the design. A fixed size is the constraint I accepted: the pool can run out, and running out is a visible failure, which is the point of not calling the heap and hoping. What I have is the allocation. What I do not have is the book.

Highlights

• Tests for the memory pool