Design a stock exchange

An exchange is a strange system: modest data, enormous message rates, and latency measured in microseconds. But the hardest requirement isn't speed. It's fairness you can prove: every order processed in the order it arrived, every trade reproducible from the record, months later, for a regulator.

1. The prompt

"Design a stock exchange: traders submit buy and sell orders, the exchange matches them and reports trades, and everyone sees the current prices."

What makes it hard:

• Fairness must be exact. Two orders at the same price are filled in arrival order; there is no "roughly".
• Latency matters at the microsecond scale, and the slowest tail matters more than the average.
• Nothing can be lost or double-counted, even across a server failure in the middle of a trade.

2. Frame the problem

3. What it must do

1. A trader can place and cancel orders and gets an acknowledgement for each.
2. The exchange matches orders by price-time priority and reports every fill to both sides.
3. Everyone receives market data: the order book's top levels and every trade, in order.

Not now: clearing and settlement (a separate system), opening and closing auctions (a follow-up), routing to other exchanges, user accounts and onboarding.

4. How well it must do it

5. Numbers that change the design

Skipped on purpose: storage for history (cheap), and user counts (irrelevant: the load is orders, not users). All figures are illustrative.

6. The nouns

• Order: who, which symbol, buy or sell, price, quantity, type, and the sequence number the exchange gave it.
• Order book per symbol: resting buy orders (bids) and sell orders (asks), by price level, oldest first within a level.
• Trade (a fill): price, quantity, the two orders, a trade id.
• Event: anything that changes a book, in the sequenced log.

order    order_id, account, symbol, side, price_ticks (integer), qty, type, tif, seq
book     symbol → bids: price → FIFO of orders · asks: price → FIFO of orders
trade    trade_id, symbol, price_ticks, qty, buy_order_id, sell_order_id, seq
event    seq (per shard, gap-free), time, kind (new | cancel | fill | …), payload   (append-only)

Prices are integers in ticks (the minimum price step), never floating point: two orders at "the same price" must compare equal.

7. The contract

Order entry (binary over TCP, or FIX)
  NewOrder      {client_order_id, symbol, side, price, qty, type, tif}
  Cancel        {client_order_id}
  ← Ack         {client_order_id, exchange_order_id, seq}
  ← Fill        {exchange_order_id, price, qty, trade_id, leaves_qty}
  ← Reject      {client_order_id, reason}

Market data (UDP multicast, one stream per channel of symbols)
  ← AddOrder / Cancel / Trade / … each with a channel sequence number
  Retransmission: TCP request for missed sequence numbers
  Snapshot: the full book every few seconds, for late joiners

The account comes from the authenticated session, never from the message. client_order_id is unique per session, so a resent order is recognised, not doubled.

Data flow: gateway (session, risk checks) → sequencer (assigns the order) → replicated log → matching engine (deterministic) → acknowledgements and fills to gateways, events to market data → trade feed to clearing.

8. First working version

Gateways, one matching engine holding every book in memory, an execution report back to the trader, and a market data publisher.

8.1 A limit order that rests

A buy at 100.02 when the best ask is 100.05 can't trade, so it joins the bid side at its price level, behind orders already there.

8.2 An order that matches

A sell for 300 at 100.00 is "aggressive": it crosses the best bid. It fills against the best price first, and within a price, the oldest order first. Each fill produces execution reports for both sides and one trade on the market data feed.

8.3 Cancel

The engine finds the order through a map from order id to its place in the book and unlinks it in O(1). If it already filled, the cancel is rejected: whatever reached the engine first wins.

9. Make it hold up

9.1 The order book latency

Matching an incoming order walks the opposite side from the best price, filling the oldest orders at each level until the order is filled or the price no longer crosses. Then any remainder rests (a limit order) or is cancelled (market or immediate-or-cancel).

9.2 One sequence, one thread fair and deterministic

Determinism has rules: no reading the clock inside the engine (time comes in the event), no random numbers, no iteration over unordered hash maps, no floating point for prices.

9.3 Surviving the loss of an engine no lost orders · failover

Periodic snapshots still help: a restarting replica loads the latest snapshot and replays only the log after it. A second data centre receives the log asynchronously for disaster recovery, accepting a small loss window there.

9.4 Market data to a thousand subscribers market data

• UDP multicast: one packet reaches every subscriber at once, so the slowest reader can't slow the others, and everyone gets it at the same time.
• Sequence numbers per channel: a subscriber that sees 101 after 99 knows it missed 100.
• Gap recovery: request missing messages from a retransmission server over TCP, or rebuild from a periodic snapshot plus the updates after it.
• Incremental updates (add, change, delete at a price level) instead of the whole book each time.
• Two identical feeds on separate networks (A/B arbitration): subscribers take whichever copy of each packet arrives first.

9.5 Microseconds latency

• No allocation on the hot path: preallocated objects and ring buffers; in garbage-collected languages, no garbage, so no pauses.
• One pinned core per engine thread, busy-polling instead of sleeping; no context switches.
• Kernel-bypass networking for gateways and market data; binary messages with fixed layouts, no parsing of text.
• Measure the tail (p99.9 and maximum), on every component, with synchronised clocks.

9.6 Risk checks before matching rules

The gateway checks each order against the account's limits (open exposure, order size) and a price band around the last trade, using state kept in memory and updated from the engine's fills. A kill switch blocks all new orders from an account instantly. These checks run before the sequencer, so a rejected order never enters the book; the engine stays simple and fast.

9.7 The whole design after the deep dives

10. Interviewer follow-ups

11. When things break

12. Wrap-up and the clock

Trade-offs we made:

• One thread per book instead of parallel matching: simpler, faster and deterministic.
• Acknowledge after replication within one data centre; the second site accepts a small loss window.
• Shard by symbol and forbid cross-symbol transactions.
• Multicast market data; subscribers repair their own gaps.
• Risk checks at the gateway, keeping the engine minimal.

What we'd watch: order-to-ack latency (p50, p99.9, max) per shard · sequencer and replication lag · rejected orders by reason · market data gaps and retransmission requests · failover drills passed.

At 10×: more symbol shards and gateways; the per-symbol design doesn't change, because no single book gets 10× bigger work than a core can do.

Common mistakes:

• A database on the matching path.
• Floating-point prices.
• Locks and many threads on one book.
• REST and JSON for order entry.
• Market data over one TCP connection per subscriber, with no sequence numbers.
• No answer for "the engine crashed between the fill and the acknowledgement".

13. Try it, check yourself, read more

Order book simulator. Send orders into a small book for one symbol and watch price-time priority work: best price first, then oldest first. Sequence numbers show arrival order.

Prices are stored as integer ticks of 0.01. Try: buy 250 at 100.06 (fills 120 at 100.05, then 130 at 100.06 from order 7, the older one there), then a market sell of 600 (it walks down the bids: 100.03, then 100.02 oldest first, then 100.00).