Loading…

The decisions that matter

Number each order at one point and give each stock one matcher thread.Priority is fair and reproducible.
Journal every input on separate racks before matching or answering.Nothing accepted is lost, and a replay rebuilds the same trades.
Check each firm’s limit in one stage before the book, reserving waiting orders.Racing orders cannot overspend the same room.
Publish market data from the matcher’s output, once, by multicast, with sequence numbers.One release for all, repairable gaps, no slowed matching.
Run hot standbys on the same journal, with a fenced Raft takeover.Trading resumes in about a second.

Architecture diagramThe final design at a glance

An order is checked and reserved in its firm’s one-at-a-time risk path, then numbered and journaled before matching; one matcher owns each stock’s book; everything after the trade reads the matcher’s numbered output. Fill reports return through the gateways. Dashed lines are asynchronous.

Diagram as text

Components: Member firms (Client); Gateways (API gateway); Risk stage (per firm) (Service); Sequencer (Service); Matcher (books in memory) (Service); Standbys (Service); Journal (separate racks) (NoSQL DB); Output stream (Queue); Feed subscribers (Client); Market data publisher (Service); Clearing feed (External API); Trade store (SQL DB). Connections: Member firms → Gateways (orders); Gateways → Risk stage (per firm) (checked); Risk stage (per firm) → Sequencer (within limits); Sequencer → Matcher (books in memory) (numbered); Sequencer → Journal (separate racks) (written first); Journal (separate racks) → Standbys (same inputs), asynchronous; Matcher (books in memory) → Output stream (each fill once); Output stream → Trade store (trades), asynchronous; Output stream → Clearing feed (trades), asynchronous; Output stream → Market data publisher (book changes), asynchronous; Market data publisher → Feed subscribers (sent once), asynchronous.

Understanding the problem

An exchange is where member firms (brokers, banks and market makers) send orders to buy and sell listed stocks, and where those orders meet. For each stock it keeps a book of waiting orders, matches each incoming order against it by a published rule, tells both sides about every trade, and publishes every change so the whole market sees the same prices.

Confirm these in the first few minutes. Three carry the design: the matching rule, nothing accepted lost when a server fails, and no member treated better than another.

Functional requirements

CoreMember firms send limit and market orders to buy or sell listed stocks, and can cancel an order or change its price or size.
CoreOrders match continuously during trading hours: the best price first, then the earliest order at that price.
CoreEach firm hears about every order it sent: accepted, filled in part or in full, cancelled or rejected.
CoreA public feed carries every trade and every change to the waiting orders, to firms and data vendors.
CoreEach firm has a credit limit its orders must not exceed, and orders that are clearly mistakes do not trade.
CoreEvery order and trade is kept for regulators.
Below the lineOpening and closing auctions.A different algorithm on the same book.
Below the lineTrading halts and circuit breakers.A status the matcher checks.
Below the lineStop orders and other order types.Each becomes a limit or market order when it triggers.

Non-functional requirements

DurabilityAn accepted order or a reported fill is never lost when any one server or rack fails; if the whole data centre is lost, at most a stated few milliseconds may be lost.
ConsistencyThe same orders always produce the same trades, and priority goes by arrival at the exchange.
LatencyAn order is answered within 1 ms of reaching the exchange, and trades are published on the public feed within 1 ms, at the 99th percentile.
AvailabilityTrading resumes within seconds of losing a server.
QualityNo member gets priority, or market data, ahead of another by how or where it connects.

Scale

From the briefNumbers here are given in the practice brief.

ScaleAbout 5,000 listed stocks and about 2,000 member sessions.
ScaleAbout 1 billion order messages a day, most of them cancels and changes; about 500,000 a second at the open and the close; up to 50,000 a second on the busiest stock.
ScaleAbout 30 million trades a day, over a 6.5-hour trading day.
ScaleAbout 10,000 market-data subscribers.

Out of scope

Out of scopeClearing and settlement.
Out of scopeThe brokers’ own apps.
Out of scopeOptions, futures and crypto custody.

Check yourself

Why is “nothing accepted is ever lost” scoped to one server or rack?
Show answerHide answer
Surviving the loss of a whole data centre with nothing lost would mean waiting for another site to confirm every order, far beyond the brief’s millisecond. So the promise covers any one machine, and a site loss has a stated window.

The numbers that shape the design

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

Rounded figures, one line of working each. Orders are small in bytes; the burst and the feed are what matter.

Back of the envelope for the equities exchange

Quantity	Value	Working
Order messages, average	About 43,000 a second	1 billion over a 6.5-hour day (23,400 seconds); the open runs at 500,000 a second, from the brief.
A day of orders on disk	About 100 GB	At about 100 bytes a message, before copies.
The busiest stock	About 5% of one core	50,000 messages a second on a core matching about a million a second.
One full-feed subscriber at the peak	About 160 Mbit/s	500,000 updates a second at about 40 bytes each.
That feed to all 10,000, one by one	About 1.6 Tbit/s	Why the feed is sent once to many.
Trades	About 1,300 a second	30 million over the trading day.

Architecture diagramWhere the load lands

Numbers are illustrative, from the brief: the open is more than ten times the average, one stock fits on a fraction of a core, and the feed is the number that does not fit.

Diagram as text

Components: An average second (Client); Gateways (API gateway); The open (Client); Sequencers (Service); The busiest stock (Client); One matcher core (Service); The full feed (Service); Every subscriber, one by one (Client). Connections: An average second → Gateways (~43,000 msgs/s); The open → Sequencers (~500,000 msgs/s); The busiest stock → One matcher core (~50,000 msgs/s, ~5%); The full feed → Every subscriber, one by one (~1.6 Tbit/s).

Try it: The numbers that shape the designGuided practice · Stock exchange, Stock exchange · Senior

Check yourself

Which number says one stock fits on a single matcher at these loads?
Show answerHide answer
The busiest stock’s 50,000 messages a second, a few percent of one core, so one thread per book is plenty.

Core entities

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

Orders and trades are records; the book is not. An order carries the broker’s own id, the stock, side, type, price, quantity and how much is left, and its status only moves forward: new, partly filled, filled, cancelled or rejected. A trade names both orders and is written once; a mistake is corrected by a new record that points at it.

The entities and their key fields

Entity	Key fields	Why it exists
Order	`order_id`, `client_order_id`, member, symbol, side, type, price (ticks), quantity, left, status, `arrived_at`	Followed from arrival to filled, cancelled or rejected.
Trade	`trade_id`, symbol, price, quantity, buy and sell order ids, taker side, `executed_at`	Both sides and clearing reconcile against it.
Stock	symbol, tick size, lot size, reference price, trading or halted	What an order for it must satisfy.
Firm limits	member, buy limit, maximum order size	What the risk stage checks against.

Architecture diagramRecords, and the one thing kept only in memory

Read:Learn: Data model design Learn: PostgreSQL

Try it: Orders, trades and the bookGuided practice · Stock exchange, Stock exchange · Senior

Keep reading+1 min

Whole numbers, and where each part lives

Prices are whole numbers of ticks and quantities whole shares, held as 64-bit integers, so 300 shares at $10.01 is exactly $3,003.00 in every report. The live book lives in the matcher’s memory, read and changed on every order; orders and trades are copied, after matching, into a store split by day and kept seven years.

Check yourself

A partly filled order is cancelled. What happens to its fills?
Show answerHide answer

The API

Firms really connect over long-lived binary sessions, the FIX protocol or the exchange’s own, but the messages fit a small contract. Every order carries an id the firm chooses; FIX calls it ClOrdID, unique for that sender within the trading day (FIX (opens in a new tab)), and FIX session sequence numbers mark retransmissions. In this design, sending the same id again after a dropped connection returns the order the exchange already has instead of placing a second one.

The messages

Message	Request	Reply
New order	`client_order_id`, symbol, side, limit or market, price, quantity, time in force	Accepted with `order_id`, or rejected with a reason
Cancel	The order, and the cancel’s own id	Cancelled with the quantity still open, or too late if filled
Cancel/replace	A new `client_order_id`, the original, new price or size	The order’s new state
Execution reports	From the last report number seen	Accepted, partly filled, filled, cancelled, rejected; each fill with `trade_id`

Architecture diagramAn order only moves forward

Diagram as text

Components: New (Component); Partly filled (Component); Filled (Component); Rejected (Component); Cancelled (Component). Connections: New → Partly filled (some trades); Partly filled → Filled (the rest); Partly filled → Cancelled (cancel); New → Rejected (fails a check).

Read:Learn: API contract design Learn: Idempotency and retries

Try it: Sending orders and hearing backGuided practice · Stock exchange, Stock exchange · Senior

Keep reading+1 min

Replies, reconnects and changes

Replies are pushed on the session as they happen and numbered, so after a reconnect a firm asks for everything after the last number it saw. A change is a cancel/replace with its own new id that names the original; a smaller size keeps the order’s place, a new price or a larger size goes to the back.

Check yourself

A cancel arrives a moment after the order’s last share filled. What does the firm see?
Show answerHide answer

High-level design

Build the design one flow at a time, following the brief: an order finding its turn, then a trade reaching everyone. The deep dives then harden each part.

An order finds its turn

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

A broker’s order reaches a gateway, which checks it is well formed and that the session may trade. The sequencer for that stock’s group gives it the next number and the exchange’s time; that number, not any gateway’s or broker’s clock, decides its turn. The order is written down on machines in separate racks before it is matched.

One matcher thread owns each group’s books in memory and applies their orders one at a time, in number order; the answer and fills go back through the gateway. Stocks are spread over matchers, so the market runs in parallel while each stock stays in one line.

The broker sends the order to its gateway.
The sequencer numbers it and writes it down.
The stock’s one matcher applies it in number order.
The broker hears “accepted” and each fill.

Architecture diagramAn order finds its turn

The sequencer’s number, given as the order arrives, decides its turn; the order is written down before the matcher sees it, and one matcher takes each stock’s orders one at a time. The answer and fills return through the gateway.

Diagram as text

Components: Broker A (Client); Gateway (API gateway); Sequencer (Service); Matcher (XYZ’s group) (Service); Journal (separate racks) (NoSQL DB); XYZ’s book (Cache). Connections: Broker A → Gateway (buy XYZ); Gateway → Sequencer (well formed); Sequencer → Matcher (XYZ’s group) (next number); Sequencer → Journal (separate racks) (before matching); Matcher (XYZ’s group) → XYZ’s book (one at a time).

Read:Learn: Consistency trade-offs Learn: Producer-consumer / work queue

Try it: An order, end to endGuided practice · Stock exchange, Stock exchange · Senior

Check yourself

Two buys for XYZ arrive a microsecond apart through different gateways. What decides which trades first?
Show answerHide answer
The sequencer’s numbering: whichever reaches it first gets the lower number, and the one matcher applies them in that order. The gateways’ clocks play no part.

A trade reaches everyone

The matcher writes each fill once, with its trade id, to a numbered output stream and moves straight on. Gateways send fill reports to both sides, the market data publisher turns it into the public feed, the clearing feed sends it to the clearing house, and the trade store keeps it. Each reader keeps its own place and records each trade id in the same write as its effect, so a slow or restarted reader neither slows matching nor counts a trade twice.

The matcher writes the fill to its output.
Gateways, the publisher, the clearing feed and the trade store each read it.
Each skips trade ids it has already handled.

Architecture diagramA trade reaches everyone, and nobody holds up the matcher

Design a stock exchange

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

The numbers that shape the design

Core entities

Whole numbers, and where each part lives

The API

Replies, reconnects and changes

High-level design

An order finds its turn

A trade reaches everyone

Sign in with Google to read the rest

Practise this

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

01Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

02The numbers that shape the design

03Core entities

Whole numbers, and where each part lives

04The API

Replies, reconnects and changes

05High-level design

An order finds its turn

A trade reaches everyone

Sign in with Google to read the rest

12Practise this

Understanding the problem

The numbers that shape the design

Core entities

The API

High-level design

Practise this