Stock Exchange

Design an electronic stock exchange system. Exchanges match buyers and sellers efficiently. NYSE: billions of matches/day; HKEX: ~200B shares/day.

Figure 1: Largest stock exchanges

Step 1 of 4: Understand the problem and establish design scope #

Goal: lock in requirements and scale.

Requirements:

1. Trade stocks only (not options/futures)
2. Order operations: place new order, cancel order (not replace)
3. Order type: limit order only (not market or conditional)
4. Normal trading hours only (no after-hours)
5. Tens of thousands of concurrent users, 100+ symbols, billions of orders/day
6. Risk checks: e.g. max 1M shares of Apple per user per day
7. Wallet management: verify sufficient funds, withhold funds for open orders

Non-functional:

1. Availability: ≥99.99% (downtime harms reputation)
2. Fault tolerance: fast recovery from incidents
3. Latency: millisecond-level round-trip (order entry → fill return). Focus on the 99th percentile
4. Security: KYC for account opening, DDoS protection for public resources

Back-of-the-envelope estimation:

1. 100 symbols, 1B orders/day
2. Trading hours: 9:30 AM – 4:00 PM ET (6.5 hours)
3. QPS: 1B / 6.5 / 3600 ≈ 43,000
4. Peak QPS: 5× ≈ 215,000 (market open/close surges)

Step 2 of 4: Propose high-level design and get buy-in #

Goal: learn the domain, then the three flows.

Business knowledge 101 #

1. Broker: intermediary for retail clients (Charles Schwab, Robinhood, Etrade, Fidelity). Provides UI for trades + market data
2. Institutional client: trades large volumes via specialized software. Pension funds (infrequent, large volume, need order splitting). Hedge funds/market makers (low latency, commission rebates)
3. Limit order: buy/sell with a fixed price. May not match immediately or partially
4. Market order: executed at the prevailing price immediately. Sacrifices cost for guaranteed execution
5. Market data levels: L1 (best bid/ask + quantities), L2 (more price levels), L3 (price levels + queued quantity at each)

Figures 2-4: Level 1, 2, 3 data

6. Candlestick chart: open, close, high, low for a time interval (1min, 5min, 1hr, 1day, etc.)

Figure 5: Candlestick chart

7. FIX protocol: Financial Information eXchange (1991). Vendor-neutral protocol for securities transactions

High-level design #

Figure 6: High-level design

Three flows:

Trading flow (critical path: latency-sensitive):

1. Client places an order via the broker's app
2. Broker → exchange
3. Client gateway: gatekeeping (input validation, rate limiting, authentication, normalization). Forwards to the order manager 4-5. Order manager: risk checks (e.g. <$1M daily volume)
4. Verify sufficient wallet funds 7-9. Order → sequencer (stamps with a sequence ID) → matching engine. Match found → two executions (fills, one each for buy/sell) 10-14. Executions returned to the client

Market data flow (non-critical path):

1. M1: matching engine → stream of executions → market data publisher (MDP)
2. M2: MDP builds order books + candlestick charts from executions
3. M3: MDP → data service (saved in specialized real-time analytics storage). Brokers subscribe → relay to clients

Reporting flow (non-critical path, accuracy-focused):

1. R1-R2: Reporter collects fields (client_id, price, quantity, order_type, filled_quantity, remaining_quantity) from orders + executions → consolidated records → database
2. Merges attributes from both sources for trading history, tax, compliance, settlements

Trading flow components #

Matching engine (cross engine):

1. Maintains an order book per symbol (list of buy/sell orders)
2. Matches buy and sell orders → produces two fills per match
3. Distributes the execution stream as market data
4. Must be deterministic: given the same input sequence → produces the same output sequence. Foundation of high availability

Sequencer:

1. Stamps every incoming order + outgoing execution with sequential IDs. Functions as a message queue + event store
2. Two instances (inbound, outbound), each with its own sequences

Figure 7: Inbound and outbound sequencers

3. Purposes: (1) timeliness/fairness, (2) fast recovery/replay, (3) exactly-once guarantee
4. Analogous to two Kafka event streams (orders in, executions out). Must be low-latency

Order manager:

1. Receives orders from the client gateway → risk check → wallet check → sends to sequencer (only necessary attributes to reduce message size)
2. Receives executions via the sequencer → returns to brokers
3. Maintains an order state machine (tens of thousands of state transitions in real systems). Event sourcing ideal for this design

Client gateway:

1. Gatekeeper, on the critical path. Functions: input validation, rate limiting, authentication, normalization. Must stay lightweight

Figure 8: Client gateway components

2. Different gateway types for retail vs institutional
3. Colocation (colo) engine: broker's trading engine on rented servers in the exchange's data center. Latency = speed of light between servers

Figure 9: Client gateway

Market data flow #

Figure 10: Market Data Publisher

MDP receives executions → builds order books + candlestick charts → publishes to the data service → brokers subscribe.

Reporting flow #

Reporter merges order attributes + execution attributes → consolidated reports (trading history, tax, compliance, settlements). Not latency-sensitive; accuracy and compliance are key.