How a matching engine works
Two participants send an order in the same instant and only one of them gets the fill. Nothing about that was decided by lottery, and nothing about it was simultaneous.
Underneath an order book venue is a program that puts arriving instructions into a single line and processes them one at a time. A surprising amount of what looks like unfairness or randomness in execution is just the shape of that line.
What the engine is
A matching engine is the component that holds the order book and applies the matching rule. It is the only thing in the system that decides whether an order rested, crossed, or was rejected.
Everything else a venue runs sits around it: the interface you typed into, the risk checks on your account, the ledger that credits balances, the publishers that broadcast market data. The engine’s job is deliberately narrow — accept a sequence of instructions, apply each one to the book, emit what happened.
Two properties explain most of its behaviour.
It is serial. Instructions are handled one after another, not concurrently. At the moment your order is being processed, no other order is being processed against that book. This is not a performance compromise; it is what makes the book a coherent object at all. If two orders could consume the same resting quantity at once, the book would have no defined state.
It is deterministic. Given the same book and the same sequence of instructions, the result is the same every time. There is no randomness in matching. What varies between runs is the sequence, not the rule applied to it.
Where “at the same time” is decided
Because matching is serial, something must convert a crowd of arriving orders into a single order of arrival. That step — sequencing — is where the outcome of your race was actually determined, and it happens before any matching.
An order travels a path roughly like this: your device, the network, the venue’s gateway, pre-trade risk checks against your account, then the sequencer, then the engine. Each hop takes time, and the times are not equal across participants. Two orders sent in the same millisecond can be sequenced several positions apart because one took a shorter network path or hit a less busy gateway.
The consequence is worth stating plainly: there is no simultaneity to arbitrate. By the time the engine sees two orders, one is strictly before the other, and the engine simply processes them in that order. “Who was first” is answered by the sequencer’s clock and the sequencer’s queue, not by when either participant pressed anything.
This is also why queue position is a mechanical fact rather than a matter of luck. It is assigned by arrival at the engine.
The matching step
For each instruction, the engine does something close to this.
Validate. Is the price a legal increment? Is the quantity above the minimum and a legal multiple? Does the account have the margin or balance the order requires? An instruction that fails here is rejected and never touches the book.
Check for a cross. Would this order match against the opposite side at its stated price? If not, the order is inserted into the book at its price level, at the back of that level’s queue, and the engine moves on.
Match, if it crosses. The engine takes resting orders from the opposite side starting at the best price and working outward, and within a price level according to the venue’s allocation rule. Each pairing produces a trade at the resting order’s price — not at the incoming order’s price. This is why an aggressive limit order can fill better than its own limit: it pays what was resting.
Emit. The engine publishes the resulting trades and book changes to the market data stream, and sends acknowledgements and fill reports back toward the accounts involved.
Note the ordering of the last two steps relative to your screen. The book changed inside the engine before anyone outside it was told. The picture you are looking at is always a report of a completed past state.
The mechanism
THE MECHANISM — an instruction through the engine
· Two orders sent in the same instant
→ not simultaneous at the engine.
The sequencer has already put
one strictly before the other.
· Order fails validation
→ rejected before matching. Never
appears in the book, never
appears in the tape.
· Order does not cross
→ inserted at the back of the
queue for its price level.
· Order crosses
→ matched outward from the best
opposite price. Trades print at
the RESTING order's price.
· Aggressive limit priced through the book
→ may fill better than its limit.
The limit is a worst case, not
the price paid.
· Your view of the book
→ NO GUARANTEE of currency. The
engine changed state before the
update was published to you.
· Sequencing, gateway topology, batching
windows and allocation rule
→ VENUE-SPECIFIC. Some sequence
continuously, some in discrete
batches.Worked example
Illustrative figures, synthetic throughout. Suppose the ask side rests as 40,004 for 1.0 unit and 40,010 for 2.0 units, and two participants each send a market buy for 1.0 unit at what they consider the same moment.
The sequencer places one of them first. That order matches the 1.0 at 40,004 and consumes the level entirely. The second order, arriving one position later, finds the best ask is now 40,010 and fills there.
Same intention, same instant, a difference of 6 per unit in the outcome. Neither participant did anything wrong and the engine applied one rule consistently. The entire difference was sequence position.
Now suppose instead the second participant had sent a limit buy for 1.0 at 40,004. It would not cross, so it would rest — becoming the new best bid, filling only if someone later chose to sell into it. That is the same price-versus-execution trade-off appearing at the level of the engine.
Batching, and the reason some venues do it
Not every venue sequences continuously. Some collect instructions over a short window and process the window as a group, allocating within it by a rule that does not depend on microsecond arrival — for example, matching everything in the batch at a single clearing price.
The reason is mechanical. Continuous sequencing rewards being nanoseconds earlier, which turns investment in speed into an advantage that has nothing to do with the price anyone was willing to trade at. Batching removes that specific race by making everything inside the window equivalent.
It replaces it with a different one — a race to be inside the current window rather than the next — and it introduces a delay between sending and knowing. Whether a venue batches, and how long the window is, is a venue design decision. This site does not rank the designs; the point is that the answer changes what “first” means on that venue.
The failure mode
The engine is authoritative and you are never looking at it. You are looking at a published description of a state it has already left.
That gap has a specific consequence for anything you do based on what you see. An order priced against a level that has already been consumed will either cross further than you expected or rest somewhere you did not intend. A cancel sent for an order that has already filled arrives too late, and the correct response from the engine is to tell you the cancel failed — which reads like an error and is not one.
The engine also does not know what you meant. It applies its rule to the instruction it received, in the position it received it. Every mechanism on this site is downstream of that: the machine is consistent, it is serial, and it is always slightly ahead of your picture of it.