c8BW

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 - Understand the Problem and Establish Design Scope

Requirements:

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

Non-functional requirements:

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

Back-of-the-envelope estimation:

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

Step 2 - Propose High-Level Design and Get Buy-In

Business Knowledge 101 #

• Broker: intermediary for retail clients (Charles Schwab, Robinhood, Etrade, Fidelity). Provides UI for trades + market data.

• Institutional client: trades large volumes via specialized software. Pension funds (infrequent, large volume, need order splitting). Hedge funds/market makers (low latency, commission rebates).

• Limit order: buy/sell with fixed price. May not match immediately or partially.

• Market order: executed at prevailing price immediately. Sacrifices cost for guaranteed execution.

• 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

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

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

Market data flow (non-critical path) #

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

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

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

Trading flow components #

Matching engine (cross engine) #

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

Sequencer #

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

Figure 7: Inbound and outbound sequencers

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

Order manager #

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

Client gateway #

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

Figure 8: Client gateway components

Different gateway types for retail vs. institutional:

• Colocation (colo) engine: broker's trading engine on rented servers in 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 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.

[Note: This chapter appears truncated — missing Step 3 (Deep Dive), Step 4 (Wrap Up), and discussions on matching engine implementation, order book data structures, deterministic replay, high availability architecture, and other technical deep dives.]