Design a Stock Exchange

Match buy and sell orders in microseconds, in a strict and provable order, never lose a fill, and stay correct when the matching engine dies mid-trade.

Last updated 2026-09-22. Difficulty: hard. Patterns: order-book, determinism, event-sourcing, low-latency, fairness. Reported at Stripe and 5 more with Pro.

Functional requirements

• Accept limit and market orders. Place, cancel and replace, each acknowledged with a deterministic outcome. An acknowledgement is a promise about a position in a sequence, not a hope.
• Match by price, then time. The best price wins; at the same price the earlier order wins. This single rule is the product, and every design choice defends it.
• Publish market data. Top of book and full depth, plus a trade tape, to thousands of subscribers with identical content and no subscriber advantaged over another.
• Report fills to the owning participant. A private stream per participant carrying their own fills and order state, which must never miss an event.
• Risk checks before an order reaches the book. Credit, position and fat-finger limits. A rejected order must never touch the book, and the check must not cost the latency budget.
• Open, close, halt and replay. Auctions at the open and close, a halt on extreme moves, and the ability to reconstruct the day exactly from the log for regulators.
• Out of scope. Clearing and settlement (T+1 with a clearing house), custody of assets, market-maker incentive schemes, and the retail brokerage in front of the exchange.

Non-functional requirements

• Matching latency (p99 < 100 µs in the engine). Measured from the order entering the engine to the fill leaving it. Microseconds, not milliseconds: this is the one system in this catalogue where the units change.
• Determinism (byte-identical replay). Replaying the input log must produce exactly the same fills in the same order. Without it there is no audit, no recovery and no failover.
• Throughput (1 M orders/s peak per symbol group). The open is several times the average. Sizing for the average means failing exactly when it matters.
• Durability of the sequence (no acknowledged order lost). An order acknowledged and then forgotten is a legal problem, not an engineering one.
• Fairness (equal access, provable order). Every participant sees a change at the same moment, to within the physics. Ordering is decided in one place and is auditable afterwards.
• Availability (failover < 1 s, no lost state). A halted market is preferable to an inconsistent one, but a market that halts often is not a market anyone uses.
• Auditability (every event retained 7 years). Regulators ask what happened at a named microsecond, years later, and expect an exact answer.

Back-of-envelope estimates

• Orders per second: ~1 M/s peak. 5 000 symbols × ~200 orders/s each at the open = ~1 M/s, and the majority are cancels: a modern market is dominated by quote updates, not by trades.
• Order-to-trade ratio: ~20:1. Market makers post and pull constantly, so roughly 20 order messages per executed trade. That is why cancel latency matters as much as match latency, and why the book is mostly churn.
• Order book memory per symbol: ~5 MB. ~50 k resting orders × ~100 B (id, participant, price, quantity, timestamp, links) = ~5 MB. 5 000 symbols = ~25 GB across the cluster: the entire market fits in the memory of a few machines.
• Event log volume: ~10 TB/day. 1 M/s at peak, averaging ~100 k/s over a 6.5-hour session ≈ 2.5 B events/day × ~200 B = ~500 GB/day of orders, and several times that with fills and book deltas: ~10 TB/day in total, retained seven years in cold storage.
• Market data fan-out: ~5 GB/s. 2 000 subscribers × full depth updates at ~2.5 MB/s each = ~5 GB/s, which is why data is multicast to a fan-out tier rather than unicast from the engine.
• Matching cost per order: ~1 µs. A price level lookup in an array indexed by ticks, then a walk of a linked list at that level: a handful of cache-friendly memory accesses, ~1 µs. The remaining 99 µs of the budget is network, serialisation and sequencing.
• Replication cost: ~30 µs. Replicating each sequenced event to two standbys in the same rack before acknowledging: ~10–30 µs on a tuned network. This is the price of not losing acknowledged orders, and it is a third of the whole budget.

Components

• Participant (FIX / binary): A broker, market maker or algorithmic trading firm, usually co-located in the same building. Sends orders and cancels, consumes its private fill stream and the public market data feed.
• Order gateway: Terminates the session, authenticates, decodes the wire protocol into the internal binary format, and timestamps arrival with a hardware clock. Deliberately thin: everything it does is on the latency budget.
• Pre-trade risk: Credit, position and sanity limits, evaluated from in-memory state in a few microseconds. Nothing reaches the book without passing it, because an exchange that lets a participant trade beyond its credit becomes the counterparty to the loss.
• Sequencer: The single point that decides order. Stamps every message with a monotonic sequence number and a timestamp, and that stamp is the definition of "first". One process per symbol group; its throughput is the market's throughput.
• Sequenced log (replicated in-memory ring + disk): The ordered, durable record of every input. The matching engines are pure functions of this log, which is what makes replay, recovery and audit the same mechanism.
• Matching engine (single-threaded, in-memory book): Consumes the log in order and applies price-time priority. Single-threaded on a pinned core with no allocation in the hot path: determinism first, and the speed follows from having no locks rather than from clever parallelism.
• Order book (in-memory, per symbol): Price levels as an array indexed by ticks, each level a linked list of resting orders in arrival order, plus a hash from order id to node for O(1) cancel. Cancels are most of the traffic, so the structure is shaped around them.
• Hot standbys: Engines consuming the same log and applying the same transitions, in lockstep. Because the engine is deterministic, a standby is not a copy of state: it is the same computation, so failover is promoting a process that is already correct.
• Market data publisher (multicast): Turns engine output into book deltas and a trade tape and multicasts them, so every subscriber receives the same packet at the same moment. Unicast would make the first recipient systematically faster, which is unfair by construction.
• Subscribers: Market makers, vendors and surveillance systems. Sequence numbers on the feed let a subscriber detect a gap and request a retransmission rather than silently trading on a stale book.
• Private fill stream: Each participant's own order state and fills, delivered reliably and in order. Unlike market data, a missed message here is unacceptable, so it is replayable by sequence number per participant.
• Event archive (object store, 7 years): Every sequenced input and output, immutable, indexed by symbol and time. The regulator's copy and the input to any replay.
• Surveillance & reporting: Replays the log to detect manipulation (spoofing, layering, wash trades) and produces regulatory reports. Runs on the same log the engine consumed, so it can never disagree with what happened.

User flows

1. A buy order crosses the spread. The path that defines the system. Note that ordering is decided once, early, and everything downstream is a consequence.
   1. A participant sends a limit buy for 500 at 101.25; the gateway decodes and timestamps it. Arrival is timestamped from a hardware clock disciplined to PTP. That timestamp is evidence, not telemetry: it is what a dispute about who was first is settled with.
   2. Pre-trade risk checks credit, position and sanity limits from in-memory state. A few microseconds against limits held locally. Fat-finger checks matter here: an order for a million shares at a tenth of the market price is far more likely a typo than an intention, and rejecting it is cheaper for everyone than unwinding it.
   3. The sequencer assigns the next sequence number for the symbol group. This is the moment "first" is decided, and it happens exactly once, in one place. Everything after it (matching, market data, audit) derives its ordering from this number rather than from a clock or a race.
   4. The sequenced event is replicated and appended to the log before it is acted on. Replicated to two standbys in the same rack, roughly 30 µs, then durable. Matching before replicating would mean a crash could produce fills that no surviving node has a record of: trades that happened and did not.
   5. The engine reads the event and walks the ask side while the price crosses. 300 fill at 101.20, 200 at 101.25, in arrival order within each level. Single-threaded, so there is no lock and no interleaving to reason about: the sequence is the concurrency control.
   6. Fills go to the private streams of both sides; the book delta and the trade go to market data. Two outputs with different guarantees: fills must never be missed and are replayable per participant; market data is multicast and lossy, with gap detection and retransmission.
   7. Positions update in the risk service and the event lands in the archive. Risk state is updated from the engine output rather than the input, so limits reflect actual exposure rather than intent. The archive write is asynchronous and off the hot path.
2. A market maker cancels and re-quotes. Twenty times more common than a trade, and where the book's data structure earns its keep.
   1. The maker sends a cancel for a resting order. Cancel latency is what determines how tight a maker dares quote: the slower the cancel, the wider the spread they need to survive being picked off. Cancel speed is therefore a market-quality feature, not just an engineering nicety.
   2. It is sequenced like any other message. Crucially, cancels take the same path as orders. A fast lane for cancels would let a maker cancel a quote after an order that was sequenced earlier, which is exactly the unfairness the sequencer exists to prevent.
   3. The engine finds the order in O(1) and unlinks it from its price level. A hash from order id to its list node makes removal a pointer update. Without it, a cancel is a scan of the level, and at twenty cancels per trade the book would spend all its time searching.
   4. If the order already filled, the cancel is rejected as too late. The classic race, and the sequence settles it without ambiguity: whichever has the lower sequence number happened first. The maker is told precisely which, so their own model of the book can be corrected.
   5. A book delta is published, and the maker immediately posts a new quote. Cancel-replace as two messages rather than one atomic operation is a deliberate choice: an atomic replace would need to hold priority across a price change, and price-time priority says a new price is a new queue position.
3. The opening auction, and the burst behind it. The scale-breaking case. Order rate is five times normal in the first seconds and the price is discovered by a different algorithm entirely.
   1. Orders accumulate during the pre-open without matching. Everything is sequenced and logged as usual; the engine simply holds them in an auction book. Reusing the same ingest path means the auction needs no separate infrastructure and inherits the same audit trail.
   2. An indicative price is published periodically so participants can react. The price that would maximise matched volume, republished every few seconds. Publishing it is what pulls liquidity in rather than leaving the open to be discovered by whoever guesses best.
   3. At the bell the engine computes the single price that maximises executed volume. One uncross: every order that can trade at that price does, at that price, with ties broken by time priority. Everyone in the auction gets the same price, which is the point: an open matched continuously would advantage whoever is physically closest.
   4. Fills are published in one burst; the book flips to continuous trading. The biggest single burst of the day: tens of thousands of fills in one sequence run. Downstream fan-out is sized for this moment, not for the average.
   5. Order rate peaks at five times normal for the first seconds. The sequencer is the bottleneck by design: there is one, and it must be fast rather than parallel. Symbol groups are the only horizontal axis, so groups are balanced by expected open-volume rather than by symbol count.
   6. A symbol too volatile to open is held in auction rather than opened badly. Price bands are checked before the uncross; outside them the symbol stays in auction and re-indicates. Delaying an open is recoverable; opening at a nonsense price and busting the trades afterwards is not.
4. The matching engine dies mid-sequence. The failure path. Because the engine is a pure function of the log, recovery is resumption rather than reconstruction.
   1. The primary engine stops responding after processing sequence 88 412 900. Detected in milliseconds by heartbeat. Trading for that symbol group pauses immediately: a pause is acceptable, two engines matching the same book is not.
   2. A standby that has consumed the same log to the same point is promoted. It is not restoring a snapshot: it has been applying every event all along, so its book is already identical. Determinism is what makes this true: same input, same code, same state, no reconciliation.
   3. Fencing ensures the old primary cannot publish if it comes back. An epoch number is incremented on promotion and carried on every output; consumers reject anything from an older epoch. Without fencing, a paused-then-resumed primary produces a second set of fills for the same orders.
   4. The new primary resumes at 88 412 901 and replays anything sequenced during the gap. Orders sequenced but not yet matched are in the log and are simply processed now. They are neither lost nor duplicated, because the sequencer (not the engine) decided they were accepted.
   5. Participants reconcile their own state from the private stream by sequence number. Each participant requests from its last received sequence and receives exactly what it missed. Gap-fill by sequence is why the private stream is reliable and replayable while market data is not.
   6. Trading resumes, typically inside a second, and the pause is published. The halt and resume are themselves published events with sequence numbers, so the gap is part of the record rather than an unexplained silence in the tape.
5. Publishing the book to two thousand subscribers. Fan-out where fairness is a physical property: the same packet, at the same moment, to everyone.
   1. The engine emits a book delta for every change. Deltas rather than snapshots: a price level changed by this much. Orders of magnitude smaller, and it is what lets full depth be published at all at this rate.
   2. The publisher multicasts the delta with a sequence number. One packet on the wire reaches every subscriber, so no subscriber is systematically earlier than another. Sending two thousand unicast copies would make the first recipient reliably faster: an advantage sold by position in a loop, which is indefensible.
   3. A subscriber detects a gap in the sequence and requests a retransmission. Multicast is unreliable by nature, so the sequence number is how a subscriber knows it missed something. Detecting a gap and knowing you are stale is far more valuable than never dropping a packet.
   4. Periodic full snapshots let a late or lost subscriber recover without a full replay. A snapshot every few seconds on a separate channel: join the delta stream, buffer, apply the next snapshot, then apply buffered deltas after its sequence. This is how a subscriber starts mid-session at all.
   5. Surveillance consumes the archived log rather than the live feed. It reads exactly what the engine read, so its reconstruction of the book cannot disagree with reality. A surveillance system built on the public feed would inherit every gap and be arguable in a way a regulator will not accept.

Deep dives

Related

• Run this question for a friend: the interviewer kit