Order Books

Venue landscape

For dark pools, PFOF, RFQ, and the full venue landscape, see trading-venues.

The previous article (trading-fundamentals) established why market makers exist. This one covers how trading happens: the data structures that organize price discovery and the matching mechanics that determine who gets filled.

The Central Limit Order Book (CLOB)

A CLOB is, at its core, two priority queues:

  • Bid side: a max-heap ordered by price (highest bid at the top), with FIFO tie-breaking at each price level
  • Ask side: a min-heap ordered by price (lowest ask at the top), same FIFO tie-breaking

Here is what a snapshot looks like:

         ASK (sell) side
Price    | Quantity | # Orders
$100.05  |   800    |    3
$100.04  |   500    |    2      <- Best Ask
         ---------
              SPREAD = $0.02
         ---------
$100.02  |   300    |    1      <- Best Bid
$100.01  |  1200    |    5
$100.00  |  2500    |    8
         BID (buy) side

Midpoint = ($100.04 + $100.02) / 2 = $100.03

The best bid and best ask together form the NBBO (National Best Bid and Offer). The midpoint is the reference price used by dark pools and for marking positions.

The matching engine enforces price-time priority: an incoming order first matches against the best available price, and among orders at the same price, the earliest arrival wins. This is the dominant mechanism for liquid instruments — equities, futures, FX spot, listed options.

How the Matching Engine Works

When a buy market order arrives, the engine walks the ask side from best (lowest) price upward, filling against resting limit orders in FIFO sequence at each level:

# Simplified sketch — see [[matching-engine-system-design#the-matching-algorithm|The matching algorithm]]
# for the full implementation with both sides, execution policies, and cancel/modify.

Notice that a large market order walks the book — it consumes the best price level, then the next, and so on. This is exactly why the effective spread diverges from the quoted spread for large orders.

Matching Engine Latency

Why do exchanges invest so heavily in minimizing matching engine latency? It is not just “faster is better.” Consider a market maker who has quotes resting on the book when new information arrives (say, a Fed announcement). The maker needs to cancel stale quotes before an informed trader picks them off. A slow matching engine means cancellation messages arrive too late — the maker gets adversely selected. The rational response is to quote wider spreads to compensate for this risk, which makes the market worse for everyone. Fast matching engines let makers quote tighter, benefiting all participants.

Price-Time vs. Pro-Rata Matching

Not all exchanges use price-time priority. Some — common in options and futures markets like CME options — use pro-rata matching: at a given price level, fills are distributed proportional to order size rather than arrival time.

The incentive structures are dramatically different:

Price-TimePro-Rata
RewardsBeing FIRST at a priceBeing LARGEST at a price
BehaviorArms race for speed (co-location, low-latency tech)Arms race for size (over-quoting, quote stuffing)
Who benefitsFast traders, technology investorsLarge balance-sheet firms
Adverse selectionQueue position is valuable; stale quotes get picked offSize commitment is valuable; small traders crowd out

Pro-rata exchanges tend to attract different participant profiles and produce different spread/depth dynamics than price-time venues.

Order Types

The two primitives:

  • Limit order: “I will buy/sell at price or better.” Adds liquidity to the book if it does not immediately match. The trader who submits a limit order provides a free option to the market — it can be picked off when information arrives.
  • Market order: “I will buy/sell at whatever the best available price is.” Consumes liquidity. Pays the spread.

Everything else is a control-flow wrapper around these two primitives:

Order TypeBehavior
Stop orderBecomes a market order when a trigger price is hit. Used for stop-losses and breakout entries.
Iceberg / ReserveOnly a portion is displayed; the hidden portion automatically replenishes as the visible part fills. Masks true order size.
Fill-or-Kill (FOK)Execute the entire quantity immediately or cancel the whole order. No partial fills.
Immediate-or-Cancel (IOC)Execute whatever quantity is available now, cancel the rest. Partial fills allowed.
Pegged orderAutomatically tracks the NBBO midpoint (or another reference price) dynamically. The exchange re-prices as the market moves.

The key insight: limit and market are what you want to do. The wrappers are execution policies — constraints on timing, visibility, and fill behavior.

Quoted Spread vs. Effective Spread

The quoted spread is what you see on the screen:

where is the best ask and is the best bid. But a large order walks the book, consuming multiple price levels. The effective spread measures the actual cost:

where is the volume-weighted average execution price and is the mid at the time of order submission. For small orders in liquid markets, . For large orders or thin books, .

Depth and Resilience

Depth at price level is simply the total quantity resting there. Aggregate depth within ticks of the best price:

Resilience is how quickly depth replenishes after a large trade sweeps it. A resilient book snaps back in milliseconds; a fragile one stays thin. This is hard to measure statically and matters enormously for execution algorithms.

Order Arrival as Queuing Theory

Model limit order arrivals at rate and cancellations at rate . At a given price level, the standing depth follows a birth-death process. The steady-state depth is under simple assumptions — and the time to fill a queue position determines expected execution time for a patient limit order.

This framing connects directly to the optimal placement problem: join a long queue at a good price (high ), or post at a worse price with a shorter queue?


Companion notebook: notebook — interactive order book simulator with depth charts, market impact analysis, and price-time priority visualization. Also see matching-engine-system-design for the full system design interview walkthrough.

Questions to sit with:

  1. Price-time priority rewards speed. Pro-rata matching rewards size. What behavior does each incentivize, and which is better for end-users? Consider: if you are a retail investor, do you care? If you are a market maker, which regime do you prefer and why?
  2. If an on-chain CLOB has 400ms latency, how does the adverse selection cost compare to a centralized exchange with microsecond latency? Think about the matching engine latency discussion — what happens to spreads?

See also