Design a Stock Exchange
Problem
Design the core of an electronic stock exchange. Brokers submit limit and market orders to buy or sell shares, and can cancel open orders. The exchange matches buy and sell orders by price-time priority and reports executions back to both sides. Everyone receives a real-time market data feed with the order book and trades. The exchange lists 5,000 symbols, handles up to 1 million order messages per second at the open, and must keep matching latency in the tens of microseconds while never losing an acknowledged order.
- Which order types are required beyond limit and market: stop orders, immediate-or-cancel, fill-or-kill?
- Do participants connect directly with a binary protocol such as FIX, or through a web API?
- Is clearing and settlement in scope, or do we hand trades to an external clearing house?
- What pre-trade risk checks are required: buying power, position limits, price bands?
- Must every participant receive market data at the same time, for fairness?
- What recovery time is acceptable if the primary matching host fails?
Items in bold are existing requirements. The rest are suggestions. Confirm with the interviewer whether they are relevant first.
- Accept limit and market orders, and cancel requests, from brokers.
- Match orders per symbol by price, then time priority.
- Send execution reports to both buyer and seller.
- Publish real-time market data: book updates and trade prints.
- Run pre-trade risk checks per broker before an order reaches the matcher.
- Hand completed trades to clearing and keep a full audit trail.
- Support trading halts per symbol and opening and closing auctions.
Items in bold are existing requirements. The rest are suggestions. Confirm with the interviewer whether they are relevant first.
- Matching latency in the tens of microseconds at p99, measured from gateway ingress to acknowledgement.
- Peak of 1 million order messages per second across all symbols.
- Determinism: replaying the same input sequence must produce exactly the same trades.
- No acknowledged order is ever lost; failover to a standby within a second.
- Fairness: messages are processed strictly in arrival order, and market data reaches all subscribers at the same time.
- Event log volume: 1 million messages per second at about 100 bytes is 100 MB per second, roughly 2 TB per trading day, archived for 7 years.
Order gateways authenticate brokers, run cheap validation, and forward orders to a sequencer that stamps each message with a global sequence number and writes it to a replicated log. A single-threaded matching engine per symbol shard consumes the sequenced stream, keeps the entire order book in memory, and emits executions and book updates as new sequenced events. Because the engine is deterministic, hot standbys replay the same log to stay in sync, and downstream systems such as market data, clearing, and reporting are all consumers of the output log.
Loading diagram...
Submit an order. A broker sends a new order over a persistent session. The gateway checks the message format and session sequence number, and the risk check verifies the order against the broker's limits held in memory. The sequencer assigns a monotonically increasing sequence number and replicates the message to the standby before it is released to the matcher.
Match. The matching engine for that symbol pops the message, compares it against the opposite side of the book, and fills it against the best prices first, oldest order first at each price. Any remainder of a limit order rests on the book. Each fill, acknowledgement, and book change is emitted as an output event.
Report and publish. The gateway sends execution reports back to both parties from the output log. The market data publisher converts book changes into incremental updates and sends them over multicast, with periodic snapshots so late joiners can rebuild the book. The clearing adapter forwards trades to the clearing house in batches.
Failover. The standby consumes the same input log and processes it in lockstep. If the primary fails, the standby is promoted at the next sequence number, and gateways reconnect to it without losing any acknowledged order.
Terminates broker sessions, validates messages, and enforces per-session throttles.
- C++ or Java with kernel bypass networking (for example DPDK or Solarflare OpenOnload).
- FIX or a binary protocol such as ITCH and OUCH style message formats.
API
NewOrder { clientOrderId, symbol, side, type, price?, quantity, timeInForce }CancelOrder { clientOrderId, origClientOrderId }ExecutionReport { orderId, status, filledQty, lastPrice, leavesQty }
Scalability
Gateways are horizontally scaled, each owning a set of broker sessions. They hold no matching state, so adding gateways adds connection capacity.
Tradeoffs
A persistent binary session is chosen over HTTP because per-message overhead and connection setup would dominate a microsecond latency budget. Validation is kept cheap here so the gateway never becomes a source of jitter.
Assigns a single total order to all inbound messages and makes them durable before matching.
- Replicated append-only log using a consensus protocol such as Raft, implemented in-process (for example Aeron Cluster) rather than a general purpose broker.
Scalability
One sequencer per symbol shard keeps throughput per log manageable. Messages are batched into replication frames to amortize network round trips while staying within the latency budget.
Tradeoffs
Total ordering at a sequencer is what makes the system deterministic and fair, and it is why the matcher can be a pure function of its input. Kafka was rejected because its millisecond-level tail latency is two orders of magnitude too slow for this path.
Single-threaded, in-memory order book per symbol that applies price-time priority.
- C++ or Java with preallocated memory and no garbage collection or allocation on the hot path.
- Pinned CPU cores, one engine thread per core.
Diagram
Loading diagram...
Data Model
- Each side of the book is a sorted map from price level to a FIFO queue of orders.
- An order index from
orderIdto its queue node gives constant-time cancel. Order(orderId, brokerId, side, price, remainingQty, sequence)
Scalability
A single thread can process several million messages per second for a symbol. Symbols are partitioned across engine instances, and the busiest symbols each get a dedicated core.
Tradeoffs
Single-threaded matching avoids locks entirely and guarantees determinism, which a multi-threaded book could not. The cost is that one symbol cannot scale beyond one core, which is acceptable because even the most active symbol stays well under that limit.
Turns output events into public feeds of book updates and trades.
- UDP multicast for low latency and equal delivery to co-located subscribers.
- A retransmission service and periodic snapshots for recovery.
Scalability
Multicast delivers each packet once to all subscribers, so fan-out cost does not grow with the number of subscribers. Internet subscribers are served by a separate tier that consumes the feed and rebroadcasts it over TCP or WebSocket.
Tradeoffs
Multicast is chosen over TCP fan-out because per-subscriber TCP streams would deliver data at different times, breaking fairness. Lost packets are handled by sequence gaps and retransmission requests rather than reliable transport.
Persist every input and output event for regulators and pass trades downstream.
- Log archiver writing to object storage in compressed columnar files; a relational store for end-of-day trade records.
Data Model
trades(trade_id, symbol, price, quantity, buy_order_id, sell_order_id, buy_broker, sell_broker, sequence, executed_at)
Scalability
About 2 TB per day of raw log is written sequentially and compressed, then moved to cold storage after a few months.
Tradeoffs
These consumers run off the output log and never on the matching path, so a slow database or clearing link can never add latency to matching. The log itself is the source of truth; any downstream store can be rebuilt by replay.