Why this matters: the matching engine is the systems interview where precision itself is the test. Every rule — priority, partial fills, cancels — has one exact answer in a real venue, and vague versions of those answers produce subtly wrong books. The requirements conversation here isn't scoping; it's demonstrating that you know financial infrastructure runs on definitions.

The prompt, as given

Design the matching core of an exchange, for a single instrument.

Orders arrive in a sequence: buys and sells, each with a price and a quantity. When an incoming order crosses with resting orders on the other side, trades execute. Whatever doesn't execute rests in the order book and waits. Latency is the product here — this engine sits on the hot path of every order the venue accepts.

Note what the prompt promises: the interviewer is holding precise answers. This round rewards candidates who extract them exactly, and quietly penalizes anyone who fills gaps with plausible-sounding approximations.

The question that separates candidates

"What exactly is the priority rule?" The answer is price-time, and both halves must be said: better price first — higher bids beat lower bids, lower asks beat higher asks — and at the same price, earlier arrival first. Candidates who say "price priority" and stop have given half a rule; the time half is what forces per-price-level FIFO ordering into the data structure, and the interviewer knows it. State the rule back in full, then say what it implies: "so within a price level I need strict arrival order, which means a queue per level." That inference, spoken aloud, is the round's first design act.

The remaining questions, and why each matters

"Limit orders only, or market orders too?" Limit orders are v1. Market orders — buy or sell at any price — arrive as a follow-up, and they carry a hidden decision: a market order that empties the whole opposite side still has unfilled quantity. What happens to the remainder is your choice to defend: reject it (clean, bounded contract) or convert it to a resting limit (at what price?). Rejection is the cleaner v1 answer; either is fine defended, neither is fine assumed.

"Partial fills?" Yes, and they're the norm: an incoming order fills against resting orders best-level-first, possibly across many resting orders, and any remainder rests in the book at its limit price. Say the consequence: a single incoming order can produce many trades.

"What must cancel cost?" Cancel is by order id, and it must be cheap. Sit with that answer for a second, because it is this problem's quiet forcing move — the same species as the allocator's free-takes-no-size. If cancels must be cheap, you cannot search the book for the order; something must already know exactly where it rests. That one requirement conjures an order-id index pointing into the book, and interviewers watch for the candidate who catches the implication at requirements time rather than during coding.

"Threads?" The engine is single-threaded on the hot path, fed by one sequenced input stream. If you propose threads for speed, expect one pushback — why might a real venue refuse that trade? — and lesson 02 gives that question the treatment it deserves.

"What's out of scope?" Risk checks, fees, auctions, multiple instruments. Order ids arrive on the input orders; the engine doesn't mint them. The latency bar: tens of thousands of orders per second, and worst case matters more than average — a venue's slowest order is the one that makes the news.

The requirement set this chapter builds against

Priority       PRICE-TIME: better price first; same price, earlier first
Order types    limit (v1); market as follow-up — remainder: YOUR call, defended
Partial fills  yes; fill best-level-first, remainder rests at limit price
Cancel         by order id, CHEAP  <- quietly forces an id index into the book
Concurrency    single-threaded hot path, one sequenced input stream
Out of scope   risk, fees, auctions, multi-instrument; ids arrive on orders
Latency        tens of thousands of orders/sec; WORST case is the bar

As always, a live interviewer's answers may differ — theirs may want market orders in v1 or a different remainder rule. The skill is extracting exact definitions and saying their structural consequences out loud.