Design a Stock Trading App

You open a brokerage app on your phone. The price of the stock you are watching flickers every second. You tap Buy, 10 shares, limit $50.00, and a few seconds later the app says "Filled at $49.98". Behind that tap, your broker did not trade anything itself: it checked your cash, wrote the order down, and sent it to an exchange it does not control, over a network that can drop the answer.

Interviewers like it because it joins two problems that pull in opposite directions. Live prices are fan-out, where a second of staleness is fine. Orders are correctness with real money, where a lost or doubled message is a disaster. The question means the app (the kind of product a retail broker such as Robinhood runs), not the exchange. The steps follow A Framework for Any Design. Try each "Your turn" box before you read on.

#Clarify the problem

• Functional: stream live quotes for the symbols a user is looking at; place market and limit orders; cancel open orders; show each order's status as it changes (sent, filled, partly filled, cancelled, rejected).
• Non-functional: quotes reach the screen within about 1 second of the exchange; an accepted order is never lost and never sent twice; status shown to the user always matches the exchange in the end; the order path stays up through the open, at about 20 times the average rate.
• Out of scope: the matching engine, options and crypto, historical charts, account opening, tax reports.

#Estimate the scale

Do prices and orders separately. These are the scenario's givens, not any real broker's figures.

• Connections: 2 million at the open. At 50,000 per push server, 2,000,000 ÷ 50,000 = 40 servers. Run 80, half full, so they can absorb a dead server's clients.
• Market data in: about 10,000 symbols, and up to 200,000 quote updates a second at the open. Nobody reads a price that changes 50 times a second, so send each symbol at most once a second: at most 10,000 updates a second, 20 times less.
• Updates out: about 10 symbols per screen, so at worst 2,000,000 × 10 = 20 million symbol updates a second. One frame per client per second makes that 2 million frames, 25,000 per server.
• Orders, average: a trading day is 6.5 hours = 23,400 seconds. 5,000,000 ÷ 23,400 ≈ 214 orders a second.
• Orders, peak: assume the first minute carries 5% of the day: 250,000 ÷ 60 ≈ 4,200 orders a second, about 20 times the average.
• Storage: about 2 KB per order with its history. 5 million × 2 KB = 10 GB a day; × 252 trading days ≈ 2.5 TB a year; about 18 TB if kept 7 years.

#Define the API

WebSocket /stream                         one per open app
  client → { "op": "subscribe",   "symbols": ["ACME", "ZETA"] }
  client → { "op": "unsubscribe", "symbols": ["ZETA"] }
  server → { "type": "quotes", "q": [ { "s": "ACME", "bid": 4997, "ask": 4999,
                                         "last": 4998, "ts": "09:30:01.200" } ] }
  server → { "type": "order", "id": "o-551", "status": "filled",
             "filled_qty": 10, "avg_price": 4998 }
 
POST /orders
  body: { "client_order_id": "c-7f3a", "symbol": "ACME", "side": "buy",
          "type": "limit", "qty": 10, "limit_price": 5000 }
  201 { "order_id": "o-551", "status": "pending" }
  200 the same body again   a retry with the same client_order_id
  422 { "reason": "insufficient buying power" | "market closed" | ... }
 
DELETE /orders/{id}
  202 { "status": "cancel_requested" }
  409 the order is already filled, cancelled or rejected
 
GET /orders/{id}          GET /orders?status=open
GET /quotes?symbols=ACME,ZETA     a snapshot for the first paint

Prices are integer cents: floating-point dollars round badly.

The decision worth arguing is what POST and DELETE promise. The outcome is decided later, at the exchange. So POST returns 201 once the order is durably recorded, DELETE returns 202, and the real result arrives as an event. An app that shows "Cancelled" on the 202 will one day show a cancelled order that actually filled.

The app creates client_order_id before the first attempt and reuses it on every retry. It is the order's idempotency key: a phone that loses the reply and resends gets the same order back.

#Model the data

orders
  order_id         BIGINT PRIMARY KEY
  account_id       BIGINT
  client_order_id  VARCHAR(40)
  symbol           VARCHAR(8)
  side             VARCHAR(4)       -- buy | sell
  type             VARCHAR(6)       -- market | limit
  qty              INT
  limit_cents      BIGINT NULL
  status           VARCHAR(16)      -- pending | sent | accepted | partly_filled
                                    -- | filled | cancel_pending | cancelled | rejected
  filled_qty       INT
  reserved_cents   BIGINT           -- cash held back for this order
  updated_at       TIMESTAMP
  UNIQUE (account_id, client_order_id)
 
fills
  exec_id          VARCHAR(40) PRIMARY KEY   -- from the exchange
  order_id         BIGINT
  qty              INT
  price_cents      BIGINT
  executed_at      TIMESTAMP
 
accounts
  account_id       BIGINT PRIMARY KEY
  cash_cents       BIGINT
  reserved_cents   BIGINT           -- spendable = cash - reserved
 
positions
  account_id       BIGINT
  symbol           VARCHAR(8)
  qty              INT
  reserved_qty     INT              -- shares held back for open sells
  PRIMARY KEY (account_id, symbol)

Access patterns: insert an order and reserve cash (or, for a sell, shares) in one step; update it as reports arrive; list an account's open orders; apply each fill once. Each is a transaction within one account, so use a relational database partitioned by account_id; the open's 4,200 orders a second spread across partitions. Quotes are not stored at all: the latest per symbol lives in the feed handler's memory.

The database's unique keys do the deduplication, so no code can race: a retried order hits UNIQUE (account_id, client_order_id), and a repeated fill hits the exec_id key.

#High-level design

The top half is the price path, the bottom half the order path. Both reach the app through the push servers.

Step through a quote, an order sent during a crash, and its fill.

#Deep dives

#Fanning out live prices

The naive design sends all 200,000 ticks a second to every watcher of each symbol. Three ideas shrink that.

• Conflate at the source. Keep the latest quote per symbol and publish once a second: at most 10,000 messages instead of 200,000. Each is the full quote, never a change, so a lost message is repaired by the next one.
• Subscribe per server, not per client. A push server subscribes to ACME once. A symbol on 1 million screens costs the pub/sub 80 messages a second, one per server; each server copies it to its own 12,500 watchers.
• Batch per client. One frame a second holds all of a client's symbols.

On reconnect, the app resends its subscriptions and gets snapshots; quotes are full state, so nothing needs replaying. Order events are never conflated, and the app also calls GET /orders?status=open after a reconnect, so a status change sent while it was away is not lost. Real-time communication covers holding connections at this scale.

#Keeping orders right with an outside exchange

Your database and the exchange cannot share a transaction, so there is always a moment when only one of them knows about the order. You choose which one.

The rule: the row with the client order id is durable before the exchange can hear about the order. Durable means committed on a synchronous replica too. Then three rules keep every case safe.

• Never resend blindly. A pending order may or may not have arrived. Order protocols such as FIX carry your client order id on every message, so ask the exchange about that id; send only if it has never heard of it. Ask only after the crashed server's exchange session is closed, so its message cannot still be on the way. A network cannot give exactly-once delivery; sending at least once plus this check gives the effect of once.
• Apply reports idempotently, forward only. Fills are keyed by execution id; filled_qty is the sum of distinct fills. A late "accepted" after "filled" changes nothing.
• Reconcile twice. Continuously, for orders stuck in pending or cancel_pending. And daily, against your clearing firm's trade report; any difference goes to a human.

Cancels race with fills. Ana taps Cancel; the exchange fills her order 10 ms later, then gets the cancel and answers "too late to cancel". So the order sits in cancel_pending, and the app says "Cancelling…", until the exchange decides.

#Surviving the open

This spike is known in advance: 9:30 every trading day. Reactive autoscaling reacts minutes after load arrives, which is too late. So:

• Scale on a schedule. Push servers, order servers and database capacity reach the open's level by 9:15.
• Spread the reconnect storm. Clients add random jitter to reconnects; snapshots come from memory, never a database.
• Drain the overnight queue at a set rate. Orders placed while the market was closed go out at the open, and exchange connections have agreed message limits. Assume 10 connections at 1,000 messages a second and 100,000 queued orders. Live orders use 4,200 of the 10,000, so the queue drains in 100,000 ÷ 5,800 ≈ 17 seconds. Tell users "at or shortly after the open", or add connections.
• Shed the right load. Charts and news give way first, never orders; cancels get top priority because they reduce risk.

#Bottlenecks and failures

At 10x, the price path grows linearly: 800 push servers, 8 GB/s. The pub/sub barely grows, because it fans out per server. Orders at 42,000 a second need more account_id partitions and more exchange connections, which take time to arrange, so plan them early.

#What a strong answer sounds like

#Follow-up questions

#How would you add stop orders?

A trigger service sends a market order when the stop price is crossed. It reads the full feed, not the conflated stream, or it can miss a brief cross. A conditional update on the stop's status makes it fire once.

#How do you show the portfolio's value live?

The app already gets quotes for its holdings, so it multiplies shares by price itself. The server sends positions on connect and after fills, instead of revaluing 2 million portfolios a second.

#How do you stop a user spending the same cash twice?

The reservation is a conditional update in the same transaction as the order insert: SET reserved_cents = reserved_cents + 50000 WHERE account_id = :a AND cash_cents - reserved_cents >= 50000. Two orders racing for the last $500 cannot both pass, because the account row is updated one transaction at a time.

#An order fills 4 of 10 shares, then the user cancels. What happens?

The exchange cancels the other 6 and the order ends cancelled with filled_qty 4. The cash reserved for the 6 is released. The cancel report and a late fill can arrive in either order, so apply each by its own key and never let a report lower filled_qty.

#How would you add a second exchange?

The order service picks the venue and writes it on the row before sending, with one connection pool per venue. The reconciler then knows which exchange to ask about a pending order.