Robinhood democratized stock trading with zero-commission trades and a mobile-first experience for 23+ million users. Designing a stock trading platform tests your understanding of order processing with strict correctness requirements, real-time market data distribution, portfolio management, and financial regulatory compliance. This is one of the most technically demanding system design questions.
Order Processing
When a user places a buy order for 10 shares of AAPL at market price: (1) The order service validates: user is authenticated, account is in good standing, sufficient buying power (cash + margin). (2) Risk check: pre-trade risk validation ensures the order does not violate: position limits, pattern day trader rules (for accounts under $25K), or restricted stock lists. (3) The order is persisted to the order database with status PENDING and an idempotency key. (4) The order is routed to a market maker or exchange. Robinhood uses Payment for Order Flow (PFOF): orders are sent to market makers (Citadel Securities, Virtu) who execute them and pay Robinhood a small rebate. (5) The market maker fills the order (fully or partially) and sends an execution report. (6) The execution service processes the fill: update order status to FILLED, update the user portfolio (add 10 AAPL shares), deduct the cash from buying power, and record the transaction in the ledger. (7) The user is notified in real-time via WebSocket push. Order types: market (execute immediately at best available price), limit (execute only at the specified price or better), stop (trigger a market order when price reaches threshold), and stop-limit (trigger a limit order at threshold).
Real-Time Market Data
The app displays real-time stock prices, charts, and portfolio values. Data sources: exchanges (NYSE, NASDAQ) provide real-time quotes and trade data via dedicated feed handlers. Market data arrives as a firehose: millions of price updates per second across thousands of symbols. Architecture: (1) Feed handlers connect to exchange data feeds via FIX protocol or proprietary APIs. They normalize the data into an internal format: {symbol, price, volume, timestamp, exchange}. (2) A message bus (Kafka or a custom low-latency pub/sub) distributes price updates to downstream services. Partitioned by symbol for ordering guarantees. (3) The price service maintains the latest price per symbol in memory (in-process cache) and Redis (shared cache). Updates are sub-millisecond. (4) WebSocket gateway pushes price updates to connected clients. Each client subscribes to symbols in their portfolio + watchlist. When a price update arrives for AAPL, the gateway pushes to all clients subscribed to AAPL. With 5 million concurrent users each watching ~10 symbols: ~50 million subscriptions. The gateway fans out updates efficiently using a pub/sub model per symbol. Optimization: batch price updates every 100ms instead of pushing every tick (reduces WebSocket message volume by 10x with negligible perceptible delay for retail investors).
Portfolio and Buying Power
Portfolio: a user holdings. Data model: position: user_id, symbol, quantity, average_cost_basis, current_market_value. Updated on every fill. Portfolio value = sum(quantity * current_price) for all positions + cash balance. Real-time portfolio value: as market prices change, the portfolio value changes. The app displays this in real-time. Computation: for each user, sum (quantity * latest_price) across all positions. With 23M users averaging 5 positions: 115M lookups per price update cycle. Optimization: compute portfolio values server-side only when the user is active (has a WebSocket connection). Push updated values every 1-5 seconds. Buying power: the amount available to purchase securities. For a cash account: buying power = cash balance – pending orders. For a margin account: buying power = cash + margin available – pending orders. Buying power must be checked atomically on order placement to prevent overspeending. Use SELECT FOR UPDATE on the user buying power record, or a Redis counter with atomic decrement. Fractional shares: Robinhood supports buying fractions of a share (0.001 AAPL). This requires decimal precision in position tracking: use DECIMAL(18, 8) in the database, not floating point.
Regulatory Compliance
Stock trading is heavily regulated by the SEC and FINRA. Key requirements: (1) Best execution — Robinhood must demonstrate that orders are executed at the best available price. This requires logging every order routing decision and the market prices at the time of routing. (2) Pattern Day Trader (PDT) — accounts under $25,000 are limited to 3 day trades in a rolling 5-day window. A day trade = buying and selling the same security on the same day. The system must track and enforce this rule in real-time. (3) Trade reporting — all trades must be reported to FINRA within 10 seconds of execution. (4) Order audit trail (OATS) — every order event (creation, modification, cancellation, execution) must be logged with millisecond timestamps for regulatory review. Retain for 7 years. (5) Market hours enforcement — regular market orders are accepted only during market hours (9:30 AM – 4:00 PM ET). Extended hours trading (pre-market 7-9:30 AM, after-hours 4-8 PM) requires explicit user opt-in and limit orders only. (6) Suitability — ensure users understand the risks of complex products (options, margin). Require questionnaires and approval levels before allowing options trading. (7) Account protection — SIPC insurance covers up to $500,000 per customer. All customer assets must be segregated from company assets.
High Availability During Market Hours
A trading platform outage during market hours causes direct financial harm to users (unable to sell during a crash, unable to buy during a dip). Robinhood has faced significant backlash for outages during volatile markets. Availability requirements: 99.99% during market hours (6.5 trading hours * 252 days/year = 1,638 hours. 99.99% = max 9.8 minutes of downtime per year). Architecture for high availability: (1) Redundant order routing — if the primary market maker is unreachable, failover to a secondary. (2) Multi-AZ deployment — all critical services (order processing, portfolio, buying power) run across multiple availability zones with automatic failover. (3) Circuit breakers — if a downstream service (market data, clearing) is degraded, degrade gracefully (show stale prices, queue orders) rather than failing entirely. (4) Load shedding during volatility spikes — when market events cause 10x normal traffic (GameStop, earnings announcements), shed lower-priority traffic (historical data, news) to protect order processing. (5) Pre-market load testing — before each trading day, run synthetic load tests to verify the system can handle the expected volume. (6) Capacity headroom — provision for 5-10x normal peak volume to absorb unexpected spikes.
{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”How does a stock trading platform distribute real-time market data to millions of users?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Market data arrives as a firehose: millions of price updates per second across thousands of symbols. Architecture: (1) Feed handlers connect to exchange feeds (NYSE, NASDAQ) via FIX protocol, normalize to internal format {symbol, price, volume, timestamp}. (2) Kafka distributes updates partitioned by symbol. (3) The price service maintains latest price per symbol in memory and Redis. (4) WebSocket gateway pushes to clients subscribed to symbols in their portfolio + watchlist. With 5M concurrent users watching ~10 symbols each = 50M subscriptions. Optimization: batch price updates every 100ms instead of every tick — reduces WebSocket message volume 10x with negligible delay for retail investors. Each symbol update fans out only to subscribed clients via a pub/sub model per symbol.”}},{“@type”:”Question”,”name”:”What regulatory requirements must a stock trading platform meet?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Key SEC/FINRA requirements: (1) Best execution — demonstrate orders execute at best available price. Log every routing decision. (2) Pattern Day Trader — accounts under $25K limited to 3 day trades per rolling 5-day window. Enforce in real-time. (3) Trade reporting — report all trades to FINRA within 10 seconds. (4) Order audit trail (OATS) — log every order event with millisecond timestamps. Retain 7 years. (5) Market hours enforcement — regular orders only during 9:30 AM – 4:00 PM ET. Extended hours require user opt-in and limit orders only. (6) Account protection — SIPC insurance up to $500K. Segregate customer assets from company assets. (7) Suitability — require questionnaires before allowing options/margin trading. Compliance is non-negotiable — violations result in fines, trading suspensions, and loss of brokerage license.”}}]}