An order-matching engine pairs buy and sell orders with strict price-time priority, extreme low latency, and perfect correctness — a uniquely demanding workload.

Orders → Gateway (validate, risk check) → Matching Engine (per symbol) ↓ in-memory order book match by price-time priority ↓ Trades → market data feed + settlement ↓ Event log (sequenced, replayable)

The order book

Two sorted sides: bids (desc price), asks (asc price) Match: incoming buy ≥ best ask → trade at resting price Priority: price first, then time (FIFO at each price level) Kept fully IN MEMORY — disk/network in the hot path is too slow

Latency & correctness

Single-threaded per symbol → no locks, deterministic ordering (LMAX Disruptor pattern: one thread, ring buffer, micro/nanosecond latency) Sequence every event → deterministic replay → audit + recovery Partition by symbol → AAPL engine independent of TSLA engine (scale out)

Reliability

Replicated event log → hot standby replays the same sequence → instant failover Determinism is everything: same inputs → same outputs on the replica Risk checks pre-trade (limits, fat-finger) at the gateway, off the hot path

Interview tip: Counter-intuitively, the matching engine is single-threaded per symbol — concurrency would break deterministic price-time ordering and add lock latency. Cite the LMAX Disruptor model (one thread, in-memory ring buffer, no locks → microsecond latency). Everything is sequenced and in-memory for determinism, which also gives you replay-based recovery and a hot standby. Partition by symbol to scale horizontally. This is a case where strong consistency and low latency are both non-negotiable.