System Design Lab›System Design Questions›Design Stock Exchange
Design Stock Exchange
HardReal-time Systemsmatchinglow-latencyevent-sourcingreal-timetransactions
Question Overview
Design the matching core of a stock exchange that handles millions of order messages per second with microsecond latency. The hard parts are a deterministic single-threaded matching engine, a sequencer and event-sourced journal that enable fast failover, and fair market data fan-out.…
Sign up to see the full question and AI interviewer
Requirements
- Accept limit and market orders, cancels, and cancel-replaces from authenticated member firms
- Inline pre-trade risk checks: credit limits, order size caps, and price bands
- Match per symbol with strict price-time priority and report executions to both parties
- Publish trades and book changes as a sequenced market data feed with gap recovery
- Median latency in the tens of microseconds; deterministic, lossless processing with seconds-level failover
- Immutable audit journal of every input and output for regulators and dispute resolution
Back-of-the-envelope numbers
- Order messages: 5B/day ÷ 23,400 s (6.5-hour session) ≈ 214K msgs/s average; open, close, and news bursts reach ~1M/s (≈ 5×)
- Per-symbol load: even a hot symbol at ~100K msgs/s is far below one core's capacity; LMAX has published ~6M orders/s on a single thread
- Order book memory: 5,000 symbols × ~10K resting orders × ~100 bytes ≈ 5 GB, held entirely in RAM
- Journal: 5B × ~100 bytes ≈ 500 GB/day, peaking at 1M × 100 bytes = 100 MB/s of sequential appends; × 252 trading days ≈ 126 TB/year
- Executions: ~2% of 5B messages trade → 100M trades/day, producing ~200M execution reports across both counterparties
- Market data: ~1M book updates/s × ~50 bytes ≈ 50 MB/s (400 Mbps); multicast sends it once, whereas TCP unicast to 1,000 subscribers needs ≈ 400 Gbps
- Latency budget: a ~50 µs acknowledgement leaves roughly 10 µs each for decode, risk, sequencing, standby replication, and matching, ruling out disk and database calls
Key components
- Order entry gateways: terminate member sessions over FIX or a binary protocol, authenticate, throttle, and validate messages before forwarding
- Pre-trade risk engine: in-memory per-member credit and position limits, fat-finger size and price-band checks, and a kill switch
- Sequencer: stamps every inbound event with a gap-free sequence number and replicates it to the journal and standby before it is processed
- Matching engine: single-threaded per symbol partition, with price levels in sorted arrays or trees, a FIFO queue per level, and an order-ID hash map for O(1) cancels
- Event-sourced journal: the engine is a deterministic state machine over sequenced input, so a hot standby replaying the same stream holds an identical book
- Market data publisher: turns engine output into incremental feeds over UDP multicast with sequence numbers, plus snapshot and retransmit servers for gap recovery
- Post-trade consumers: drop copies, clearing and settlement, surveillance, and regulatory reporting read the journal asynchronously, off the hot path
Common mistakes
- Putting a database write or distributed transaction on the matching path, adding milliseconds where the budget is microseconds
- Multi-threading one order book with locks, which adds contention and makes execution order nondeterministic and impossible to replay
- Using wall-clock time, random numbers, or unordered map iteration inside engine logic, so a replaying standby diverges from the primary
- Choosing a book structure without O(1) cancel even though cancels and modifications make up most order messages
- Chaining microservices over HTTP and JSON, where a single hop costs more than the entire latency budget
- Publishing market data over per-subscriber TCP, which multiplies bandwidth and lets some subscribers systematically see data first
Likely follow-ups
- How does the standby take over mid-session without losing or duplicating a single order?
- How would you run an opening auction that computes one clearing price for all accumulated orders?
- How do you keep processing fair for members whose servers sit at different distances from the gateways?
- What would you do if a single symbol's message rate exceeded what one core can process?
- How would you implement a member-wide kill switch that cancels thousands of orders instantly?
- How would you enforce risk limits that span many symbols handled by different matching engines?
No community solutions yet
Be the first to publish your solution
Practice ‘Design Stock Exchange’ with an AI Interviewer
Get scored feedback on your diagram, scalability approach, and trade-offs. Free while we grow — up to 3 full interviews a day.