Design a Real-Time Stock Trading System

A stock trading system must accept orders, match buy and sell orders in real time, and produce correct executions under strict latency and consistency constraints. In interviews, the matching engine is the core: it must enforce price-time priority (best price first, then earliest time).

This walkthrough follows the Interview Framework and focuses on what you'd present in a 45-60 minute interview.

Phase 1: Requirements (~5 minutes)

Functional Requirements

1. Users should be able to place buy/sell limit orders with (symbol, side, price, quantity, time)
2. Users should be able to cancel open orders
3. System should match orders in real time using price-time priority
4. Users should be able to query order status and executed trades
5. Clients should receive live market updates (top of book and trade ticks)

Non-Functional Requirements

Capacity Estimation

Assume:

• 10M daily active traders
• 1B orders/day
• Peak factor 10x around market open

Average QPS  = 1,000,000,000 / 86,400 ~= 11,600 orders/sec
Peak QPS     ~= 116,000 orders/sec
Order size   ~= 200 bytes
Ingress/day  ~= 200 GB raw (before replication/indexes)

Phase 2: Data Model (~5 minutes)

Core Entities

Order
├── order_id (PK)
├── user_id
├── symbol
├── side: BUY | SELL
├── type: LIMIT | MARKET
├── price (nullable for MARKET)
├── quantity
├── remaining_quantity
├── status: NEW | PARTIALLY_FILLED | FILLED | CANCELED | REJECTED
├── created_at (exchange timestamp)
└── partition_key (symbol)

Trade
├── trade_id (PK)
├── symbol
├── buy_order_id
├── sell_order_id
├── price
├── quantity
├── executed_at
└── sequence_number (monotonic per symbol)

OrderBookLevel
├── symbol
├── side
├── price
├── aggregate_quantity
└── order_count

Account
├── user_id (PK)
├── cash_balance
├── buying_power
└── updated_at

Relationships

• Order generates zero or more Trade rows until fully filled/canceled.
• Trade is immutable and drives downstream positions, balances, and market data.
• OrderBookLevel is derived state for fast read APIs/WebSocket streams.

Phase 3: API Design (~5 minutes)

Protocol Choices

• Client order entry: REST over HTTPS (simple and standard)
• Low-latency internal services: gRPC
• Live market stream / order updates: WebSocket

Key Endpoints

POST /v1/orders
{
  "symbol": "AAPL",
  "side": "BUY",
  "type": "LIMIT",
  "price": 180.25,
  "quantity": 100,
  "client_order_id": "abc-1"
}
Response: { "order_id": "o789", "status": "NEW" }

POST /v1/orders/{order_id}/cancel
Response: { "order_id": "o789", "status": "CANCELED" }

GET /v1/orders/{order_id}
Response: { "status": "PARTIALLY_FILLED", "filled_quantity": 40, ... }

GET /v1/order-book/{symbol}?depth=20
Response: { "bids": [[180.25, 500]], "asks": [[180.30, 300]] }

WS /v1/stream
Channels: order_updates, trades, top_of_book, depth

Phase 4: High-Level Design (~15-25 minutes)

Core Components

Matching Flow

1. Client sends order to API; system authenticates and checks risk.
2. Router maps symbol -> partition (single writer per symbol).
3. Partition leader appends the order command to replicated durable log.
4. Matching engine applies the command in sequence, checks opposite-side best price, and generates trade events.
5. Engine appends resulting events (order accepted, trade executed, order filled) and ACKs only after replication quorum.
6. Async consumers update DB projections and push WebSocket updates.

Price-Time Priority Implementation

• Buy book: max-heap by price, FIFO queue at each price level
• Sell book: min-heap by price, FIFO queue at each price level
• For equal price, dequeue oldest order first

Phase 5: Scaling & Trade-offs (~15-20 minutes)

How This Meets Non-Functional Goals

1. Low latency: in-memory order books and single-threaded matching loop per partition
2. High throughput: horizontal scaling by symbol partitions
3. Consistency: total order guaranteed inside each symbol partition
4. Durability: write-ahead append to replicated log before acking order acceptance
5. Availability: active-standby engine replicas with fast leader failover

Bottlenecks and Solutions

Key Trade-offs

1. Strong ordering vs availability
   • Strong ordering per symbol requires one active leader; failover can briefly pause writes.
2. Latency vs durability
   • Waiting for replicated log ack increases latency but avoids data loss.
3. Global fairness vs scalability
   • We guarantee fairness per symbol partition, not global cross-symbol ordering.

Deep Dive: Cancel vs Fill Race

When cancel and fill arrive close together, resolve by partition sequence order:

• If cancel is sequenced first, remaining quantity is canceled.
• If fill is sequenced first, execution stands; cancel applies only to leftover quantity.

This deterministic rule prevents inconsistent states across services.

Common Pitfalls

Interview Checklist

• Clarified order types and matching rule (price-time priority)
• Stated latency/throughput/consistency targets
• Proposed symbol partitioning with single-writer matching
• Explained durability strategy (event log + replay)
• Covered cancel/fill race and hot-symbol scaling

Summary