Design a Real-Time Stock Brokerage (Robinhood / Trading System)

Retail stock brokerages handle two vastly different workloads: an ultra-low latency, CPU-cache-friendly order matching engine, and a massive real-time market data dissemination fanout to millions of active mobile screens.

1. System Requirements

Functional Requirements

1. Place Orders: Users can place Market, Limit, and Stop-Loss orders for equity tickers.
2. Order Execution & Matching: Match buy and sell orders based on Price-Time Priority (FIFO).
3. Real-time Market Data: Stream live Level 1 (BBO: Best Bid / Offer) and Level 2 (order book depth) quotes to millions of mobile apps.
4. Portfolio & Balances: Instantly update user portfolio values and buying power as positions shift.
5. Trade Confirmation & Regulatory Audit: Immutable, timestamped records for FINRA / SEC compliance.

Non-Functional Requirements

1. Order Execution Latency: Internal routing and matching engine latency $< 5\text{ms}$.
2. Market Data Fanout Latency: Under 200ms from stock exchange tick to retail client glass.
3. Zero Data Loss: Orders and fills must be durably journaled before acknowledgment.
4. Concurrency & Race Condition Prevention: Prevent negative cash balance under high-frequency trading.

2. Order Book Matching Engine Architecture

          LIMIT BUY ORDERS (BIDS)              LIMIT SELL ORDERS (ASKS)
      [Price: $150.00] -> [100 sh, 50 sh]   [Price: $150.05] -> [200 sh]
      [Price: $149.95] -> [300 sh]          [Price: $150.10] -> [500 sh, 100 sh]
      [Price: $149.90] -> [1000 sh]         [Price: $150.25] -> [450 sh]
                      ^                                    ^
                      |                                    |
             HIGHEST BID: $150.00                 LOWEST ASK: $150.05
                                                          /
                       ====== SPREAD: $0.05 =============/

• Data Structure: A double-ended B-Tree or SkipList indexed by price. Each price level points to a doubly linked list of individual orders maintaining FIFO arrival order.
• Concurrency Model (LMAX Disruptor Pattern): Rather than using mutex locks across threads, the matching engine runs single-threaded pinned to a dedicated CPU core. It reads orders sequentially from a lock-free circular ring buffer, processing over 1,000,000 orders/sec without lock contention.

3. High-Level Architecture Blueprint

                           +-----------------------+
                           |  Retail Mobile Apps   |
                           +-----------+-----------+
                                       |
                                       | TLS / WebSockets
                                       v
                           +-----------------------+
                           |   API Gateway & Edge  |
                           +-----+-----------+-----+
                                 |           |
        +------------------------+           +------------------------+
        | Place Order                        | Market Data Stream
        v                                    v
+------------------------+           +------------------------+
| Order Gateway Service  |           | Market Data Fanout Svc |
| (Balance Verification) |           | (Redis PubSub / WSS)   |
+-----------+------------+           +-----------+------------+
            |                                    ^
            v In-Memory Journal                  | Live Ticks
+------------------------+           +-----------+------------+
| Matching Engine Cluster|           | Exchange Feed Handler  |
|  (C++ / Rust Engine)   |           | (Nasdaq / NYSE Feed)   |
+-----------+------------+           +------------------------+
            |
            v Fills & Executions
+------------------------+
| Clearing & Ledger Svc  |
| (PostgreSQL Database)  |
+------------------------+

4. Staff-Level Deep Dives

Deep Dive 1: Balance Pre-allocation & Atomic Buying Power Check

A user with $1,000 buying power should not be able to execute three parallel $1,000 market buys on volatile meme stocks.

1. When an order arrives at the Order Gateway, a Redis Lua script conditionally checks and holds buying power:

   local balance = tonumber(redis.call('get', KEYS[1]))
   local cost = tonumber(ARGV[1])
   if balance >= cost then
       redis.call('decrby', KEYS[1], cost)
       return 1
   else
       return 0
   end

1. If approved, the order advances to the matching engine.
2. If the limit order cancels or fills at a better price, the surplus held balance is atomically refunded.

Deep Dive 2: Real-time Market Data Fanout at Scale

• Millions of users watching the AAPL ticker creates a massive fanout explosion.
• Conflation & Throttling: The human eye cannot process 1,000 quote changes per second. The edge market data gateways conflate ticks: if 20 price updates arrive in 100ms, only the latest quote is pushed across the client WebSocket, saving 90% bandwidth.

Key Architecture Trade-Offs & Decision Matrix