Requirements & API: Stock Exchange (Matching Engine)

What an interviewer expects you to nail down before drawing a single box.

Functional

  • Authenticate and validate orders, then totally-order them with a sequencer before matching.
  • Match crossing orders by strict price-time-priority and emit executions; rest the remainder on the book.
  • Run risk and funds (wallet) checks before an order can affect the book; support cancels and modifications.
  • Publish a market-data feed and write every order/execution to a reporting store for audit and reconciliation.

Non-functional

  • Deterministic matching: the same sequenced input must always produce the same trades, with no eventual consistency.
  • Microsecond-grade matching latency; the hot path stays in-memory and single-threaded per symbol.
  • Complete auditability. Regulators (SEC/MiFID) must reconstruct every book event exactly from the sequenced log.
  • No acknowledged trade lost on crash: a hot standby replays the sequencer's log to recover the exact book state.

API contract

NewOrder { symbol, side, qty, price, type } → { order_id, seq_no }
FIX/OUCH binary on the hot path; the sequencer's seq_no fixes total order before matching.
CancelOrder { order_id } → { status }
Removes a resting order; no-op if already filled.
ExecutionReport { order_id, fill_qty, fill_price, ts } (outbound)
Pushed back to the firm through the outbound sequencer as the order matches.
MarketData (multicast) { symbol, event: add|cancel|trade, price, qty }
UDP multicast of every book event, built by the market data publisher.

About Stock Exchange (Matching Engine)

Think about two people trying to buy the very same share at the very same instant, with millions of dollars riding on who gets it. A stock exchange has to decide, fairly and in microseconds, and it can never let both of them win. There is no 'eventually correct' here. The same orders fed in the same sequence must always produce the exact same trades.

Here is the whole thing in plain terms. A client gateway authenticates the firm, validates and normalizes the order, and passes it to an order manager. The order manager runs a risk check and a wallet check, reserving the cash or shares so an order can never overspend. The order then goes to the sequencer, which stamps every order with a sequence number so the whole stream is totally ordered before anything matches. The matching engine keeps an in-memory order book per symbol, with the buy side and sell side as two priority queues sorted by price and arrival time. Each incoming order either crosses a resting order and produces a trade, or rests on the book.

The matching engine is single-threaded per symbol, and that is deliberate. Think of one cashier serving a single line: nobody can be served out of turn, so the outcome is never ambiguous. Two threads racing on AAPL could match the same resting order twice. You scale by sharding across symbols, AAPL on one box and MSFT on another, never by splitting one symbol's book.

The sequencer is also the event store. Because the book lives only in RAM, the sequenced log is the real source of truth. If the AAPL matcher crashes, a hot standby replays the log up to the last sequence number, reaches the identical book state, and takes over within seconds. No acknowledged trade is lost or duplicated, because the sequencer fixed the order.

From the execution stream, two more paths fan out off the hot path. A market data publisher builds the order-book views and candlestick charts and multicasts them to brokers and terminals. A reporter writes every order and execution to a database for books-and-records, tax, and reconciliation. Settlement, the actual movement of cash and shares, happens later on a T+2 timeline through clearinghouses. This system teaches price-time-priority matching, why a sequencer plus single-threaded-per-symbol design buys determinism, event-sourced recovery, and why market data rides UDP multicast to reach tens of thousands of subscribers from one packet.