Design an Order-Matching Engine

The first move is to picture the thing it builds: a limit order book. On one side sit the bids, the buy orders, ranked from the highest price down. On the other side sit the asks, the sell orders, ranked from the lowest price up. The best bid and the best ask face each other across a small gap called the spread. A new order that is willing to pay at least the best ask, or sell at most the best bid, crosses that gap and trades immediately. Everything in this design is about maintaining that book and matching against it. Correctly, and fast.

The matching rule is price-time priority. State it precisely, because the engine enforces it on every single order. Better prices match first: a buyer willing to pay more gets filled before a buyer offering less. Within a single price, the earliest resting order matches first, first in, first out. So an incoming aggressive order walks the opposite side of the book. It takes the best price level, drains its queue in arrival order, then moves to the next, until the order is exhausted or no price still crosses. Each pairing is a trade. A large order can sweep many resting orders across several levels and generate a fistful of trades in one pass. Whatever quantity of a limit order does not fill rests in the book at its limit price and waits.

Two facts about an exchange warp the design before a single box is drawn. One is that the answer must be the same every time. Feed the engine the same orders in the same order and it has to produce the same trades on every machine that runs it. Real money changes hands on the result, and a regulator can ask you to prove what happened. The other is speed. A busy trading pair takes hundreds of thousands of orders per second at peak, and traders measure the engine's response in microseconds. Those two pulls, perfect determinism and raw throughput, point at one unusual answer that a database-first design misses.