Stock Exchange Order Matching System Design Template

System Design: [Exchange or matching venue name]

Reference design for the core of an electronic exchange: order entry gateways, pre-trade risk checks, a sequencer that puts every input in one total order, single-threaded deterministic matching engines that keep a limit order book per instrument with price-time priority, and a market data feed. It names the FIX Trading Community specifications that such venues commonly expose (FIX Latest application messages, the FIX session layers and Simple Binary Encoding) as references only, sizes the system with worked numbers, and covers replication, recovery by replay and the failure behaviour of each component. It follows the structure of the System Design Document template, adds a 45-minute interview path, access-pattern and failure-mode tables and a cited "How real systems do it" box, and is pre-filled with a worked design to adapt. Replace every [bracketed] value and every row marked Example; values marked Example are assumptions, not benchmarks. Market rules and regulation differ by jurisdiction; this is a design format, not legal or regulatory advice, so check the current official texts and qualified counsel.

Document control

Approvals

Revision history

Contents

1. Overview
2. Requirements
3. Capacity estimation
4. API design
5. Data model
6. High-level design
7. Detailed design
8. Scalability and performance
9. Reliability, security and operations
10. Trade-offs and alternatives
11. Delivery plan and risks
12. Appendices

1. Overview

1.1 Problem statement

[Example: The venue's current matching platform runs on a shared relational database with row locks per order book. At the market open, order acknowledgements reach 40 ms at p99, two members reported executions in a different order from their submissions, and recovering from a node failure took 25 minutes of manual reconciliation. The venue plans to list 10 000 instruments and must handle a peak of 1 million order messages per second.]

1.2 Proposed solution

[Example: Members connect to order entry gateways that authenticate, decode and run pre-trade risk checks. Accepted messages go to a sequencer that stamps each with a 64-bit sequence number and a timestamp, writes it to a replicated journal and only then releases it to the matching engines. Each engine owns a partition of instruments, runs on one thread, keeps the order books in memory and is fully deterministic, so a primary and a hot standby that read the same sequence produce the same executions. Engine output feeds execution reports to members, a multicast market data feed and the clearing interface. Recovery is snapshot plus replay of the journal.]

1.3 Decisions requested from reviewers

1.4 45-minute interview path

Use this order when the document serves an interview or a short design review. The written sections below are the long form of each step.

Start the default deep dive by drawing a small book: two sides, price levels sorted best first, a first-in first-out queue of orders at each level. Walk one aggressive order through it (7.2) and then ask what would happen if two threads matched the same book at once. That leads to the single-writer engine and the sequencer.

2. Requirements

2.1 Core functional requirements

2.2 Non-functional requirements

2.3 Below the line (out of scope)

Name these explicitly so reviewers and interviewers do not pull the design toward them.

• [Example: opening and closing call auctions (a later release; same engine, different matching phase)]
• [Example: clearing, settlement and margin (the clearing house receives a trade feed)]
• [Example: options, multi-leg and implied orders]
• [Example: member onboarding, billing and surveillance analytics (consume the journal offline)]
• [Item deferred, with the release that will take it]

3. Capacity estimation

3.1 Assumptions

3.2 Message rates

Trades: $25 \times 10^{6} / 23\,400 \approx 1\,068$ per second on average, about 2% of messages. Most traffic is new orders and cancels that never trade, so the engine is optimised for insert and cancel, not only for matching.

Busiest instrument at peak: $h \times m_{p} = 0.05 \times 10^{6} = 50\,000$ messages/s, so one thread has $10^{6} / 50\,000 = 20 \ \mu s$ per message for that instrument. One core per instrument partition is enough as long as matching takes a few microseconds; no instrument needs to be split across threads.

3.3 Engines

The 0.5 factor keeps engines at or below 50% busy at peak so queues stay short. The design uses 8 partitions so the hottest instruments can be spread and a partition can move without overloading another.

3.4 Memory, journal and market data

Order books: $O \times o = 5 \times 10^{6} \times 128 \ \text{B} = 0.64 \ \text{GB}$ across all partitions, so every book lives in memory with room to spare.

Journal: $1.17 \times 10^{9} \times 64 \ \text{B} \approx 74.9 \ \text{GB/day}$, about 225 GB/day with three copies, and about 18.9 TB per year of 252 trading days for one copy. Retention follows the venue's record-keeping rules.

Market data: $1.17 \times 10^{9} \times 40 \ \text{B} \approx 46.8 \ \text{GB/day}$. At peak, $10^{6} \times 40 \ \text{B} = 40 \ \text{MB/s} = 320 \ \text{Mbit/s}$ per feed, 640 Mbit/s for the A and B copies. Multicast makes this independent of the number of subscribers.

3.5 Recovery time

A full-day replay takes $1.17 \times 10^{9} / (5 \times 10^{6}) = 234$ s. With a snapshot every 5 minutes, the worst case is 5 minutes of peak traffic, $300 \times 10^{6} / (5 \times 10^{6}) = 60$ s of replay, which meets the cold restart target. Hot standbys do not replay at all; they are already current.

A 64-bit sequence number at $10^{6}$ messages per second lasts about 585 000 years unsigned (about 292 000 years as a signed 64-bit integer), so it never wraps.

3.6 Summary

4. API design

4.1 Interfaces

FIX message types named for orientation (check the FIX Latest definitions before implementing):

4.2 Internal message after the gateway

Gateways convert both protocols to one internal fixed-size message. Prices are integers in ticks; floating point is never used for prices or quantities.

{"seq": 418220931, "ts_ns": 1793433600123456789, "type": "new", "member": "MBR-0042", "client_order_id": "c-77120", "instrument": 1207, "side": "buy", "ord_type": "limit", "tif": "day", "price_ticks": 1003, "qty": 400, "stp_group": "G-3"}

4.3 Rejects and idempotency

The member's client_order_id is unique per session and day, which makes resends after a reconnect safe.

5. Data model

5.1 Entities

The journal of sequenced inputs is the source of truth; books, executions and market data are all derived from it by the deterministic engine.

5.2 Storage choices

5.3 Access patterns

6. High-level design

7. Detailed design

The deep dives in this section, each with options, choice and reason:

7.1 Order book and market model

• Priority: best price first; at the same price, earliest sequence number first (price-time priority).
• Trade price: the price of the resting (passive) order.
• Replace: a quantity decrease at the same price keeps priority; a price change or a quantity increase takes a new priority sequence.
• Structure per instrument and side: price levels in an array indexed by price_ticks - base, sized to cover the price collar, with a sorted tree for the rare level outside it; each level holds a doubly linked FIFO list and its total quantity; a hash map from order_id to the list node gives O(1) cancel.
• Best price is cached and updated on insert, fill and cancel.

7.2 Matching walk-through

Example: sell side of instrument 1207 before the order arrives (tick size 0.01, prices shown in currency units):

Incoming B-9: buy limit 400 at 10.03, Day.

B-9 is fully filled: 400 shares, notional 4 009.00, average price 10.0225. S-3 rests with 200 at 10.03 and keeps its original priority. S-3 has an earlier sequence than S-2 but trades later, because price beats time. The engine emits three executions, each with a fill report to both sides, and order-by-order market data for each change.

7.3 Determinism, sequencing and recovery

The engine is a state machine: next state and output depend only on the current state and the next sequenced input. To keep that true:

Sequencer: one leader and two followers in the primary site. The leader assigns the sequence number, appends to its journal and forwards to the followers; a message is released to the engines once a majority (2 of 3) has it on disk. A copy streams asynchronously to the DR site; the DR recovery point is the replication lag, stated in the business continuity plan. Leader election uses a consensus protocol (see system-design/design-distributed-lock-coordination).

Engines: each partition has a primary and a hot standby reading the same sequence. Both hash their output every 10 000 messages; a mismatch halts the partition for investigation rather than risking a wrong trade. Failover promotes the standby, which is already current; members see a short pause, not lost orders.

Cold restart: load the latest snapshot of the partition, replay the journal from its sequence number (3.5), compare the output hash with the recorded one and resume.

7.4 Pre-trade risk and market controls

Each member is pinned to one gateway pair, so credit state has a single writer. Fills flow back to the gateway and release or consume credit.

7.5 Market data

• Every output event carries the partition sequence number; the feed carries a channel sequence number so subscribers detect gaps.
• Two identical multicast feeds (A and B) travel on separate networks; subscribers take the first copy of each sequence number.
• A subscriber that detects a gap requests the missing range from the TCP retransmission service, or, after a long outage, joins the snapshot channel and then applies incremental messages after the snapshot's sequence number.
• Public data never contains member identities.

7.6 How real systems do it

How real systems do it (paraphrased, not copied). Martin Fowler's article "The LMAX Architecture" (12 July 2011) describes the retail trading platform built by LMAX. All business logic runs on a single Java thread with every object in memory and no database; the article reports around 6 million orders per second from that one thread on one commodity server. Input events pass through a ring buffer (the Disruptor) where separate consumers unmarshal, write the journal and replicate the events before the business logic sees them, and output goes through further ring buffers. Because state is rebuilt by replaying the durable input events (event sourcing) from a nightly snapshot, a full restart took under a minute, and replicas fed the same input in the same order can take over quickly. The same three ideas drive 7.3: a single writer per partition, a journal of inputs before processing, and determinism so replicas agree. Read the original in 12.3; this box keeps only the general idea.

8. Scalability and performance

Latency budget, order in to acknowledgement out (target p99 100 µs):

Keep the hot path free of memory allocation, system calls and locks; pin threads to cores; use kernel-bypass networking. Measure with hardware timestamps at the network edge, not with application clocks.

9. Reliability, security and operations

9.1 Failure modes

9.2 Security and integrity

9.3 Observability and regulatory records

Trading venues are usually subject to rules on clock synchronisation, record keeping and market controls. In the EU, for example, Commission Delegated Regulation (EU) 2017/574 sets clock-synchronisation requirements under MiFID II; the UK and US have their own regimes. Confirm the rules that apply to the venue and their current text with compliance before setting NFR-07 and retention. This template does not state the legal requirements.

9.4 Cost estimate

10. Trade-offs and alternatives

11. Delivery plan and risks

11.1 Milestones

11.2 Rollout and rollback

[Example: Instruments move to the new platform in groups over a weekend with no open orders carried across (Day orders only during migration). Rollback moves the group back before the next session; the old platform stays warm until M5 plus 60 days.]

11.3 Risks

12. Appendices

12.1 Open questions

12.2 Glossary

12.3 References

Standard and licence note

Based on common industry practice for electronic matching venues. FIX specifications are published by the FIX Trading Community; they are named here for reference only, message type codes are quoted for orientation and no specification text was copied. Official text: FIX Trading Community, access under its terms at https://www.fixtrading.org/standards/. ISO/IEC 25390:2025 (SBE) is a paid standard and is named only; official text: ISO, purchase or licensed access at https://www.iso.org/standard/90107.html. The LMAX article is paraphrased in 7.6 only. Regulatory items are examples, dated October 2026; this is not legal or regulatory advice, so check the current official text and a qualified professional. All capacity numbers are illustrative examples. Original text written for this collection. Template licence: MIT.