Design Stock Trading Platform

A retail brokerage app lets ordinary people buy and sell stocks from their phone. The user sees a price ticking, taps buy, and a moment later owns shares. Behind that tap the broker has to check that the user can afford the order, route it to a market maker or exchange, track partial fills that arrive over the next few hundred milliseconds, update the account, and later settle the trade with a clearing house one business day after it happened.

Two very different workloads share the app. The money path handles orders, cash and positions, where a single lost fill or double-counted deposit is a regulatory problem. The market data path streams prices to a million or more open screens, where being a second late is fine but falling over at the market open is not. A good design treats them as separate systems with different consistency rules.

Assume 18 million funded accounts, 4 million users opening the app on a typical trading day, and up to 1.5 million connected at the market open. Orders average 6 million a day, but they arrive very unevenly.

Every money field is a decimal string. Floating point cannot represent 0.1 exactly, and a broker that loses fractions of a cent per trade across millions of trades will have an audit problem.

On the money path, the order service validates a request, checks and holds buying power in the ledger, and writes an order created event, all in one database transaction. A transactional outbox then publishes the event to Kafka, where the order router picks it up, decides which venue to send it to and sends it over a FIX session. Execution reports come back to the execution handler, which records fills as new order events and moves cash and shares in the ledger, again in one transaction per fill.

On the market data path, feed handlers read the consolidated and direct exchange feeds, normalise them, and publish the latest quote per symbol onto an in-memory quote bus. WebSocket edge servers subscribe to the symbols their connected users care about and, once a second, send each user one frame with the latest values. The same sockets carry order updates, which the edge receives from Kafka filtered to the users connected to it.

A third, slower path runs after the close: reconciliation and settlement. Trades are reported to the clearing firm, settlement happens one business day later, and every night the broker compares its own records of cash, positions and trades against the clearing firm's files and the bank's statements.

Store each order as an append-only list of events, not as a row whose status column is overwritten. The current state is a fold over the events, and a materialised orders_current table is updated in the same transaction for fast reads. This gives an exact audit trail for free, makes it obvious when a fill arrived relative to a cancel request, and lets you rebuild any account's history by replaying.

Notice the arrow from pending cancel to filled. A cancel is only a request until the venue confirms it. The order can fill in the meantime, and the system must accept that fill and update the account. Treating cancel as instant is a common bug that leaves a user owning shares the app says they do not have.

No network protocol gives true exactly-once delivery. What you build is at-least-once delivery plus idempotent handling at every hop, which produces exactly-once effects on the account. The outbox pattern closes the last gap: the order event and the message to Kafka are written in the same database transaction, so the router can never miss an order the user was told was accepted.

Buying power is the amount a user can spend right now, and it moves for many reasons: fills, cancels, deposits clearing, sells settling, margin changes. Storing it as a single number and adjusting it from many places invites drift. Instead, compute it from the ledger.

Placing a buy order writes a hold to the ledger for its maximum cost: limit price times quantity, or a collared price for market orders. Each fill converts part of the hold into a debit at the actual price and releases the difference. A cancel releases what is left. All of this happens in transactions on the user's account partition, with a row lock on the account balance row, so two orders placed at the same instant cannot both spend the same dollars.

Market buy orders have no price, so the hold needs a guess. A common choice is to convert them into limit orders with a collar a few percent above the current ask. That protects the user from a fill at a wildly bad price in a fast market and gives the ledger a firm maximum to hold.

A bank transfer through ACH takes one to three business days to settle and can be reversed days later if the user's bank rejects it. Users hate waiting, so brokers extend instant credit for part of the deposit, for example the first 1,000 dollars. That credit is a loan. If the transfer bounces after the user bought and lost money on a volatile stock, the broker carries the loss.

So instant credit is limited by account age, history and risk score, and the positions bought with it cannot be withdrawn as cash until the deposit settles. When a reversal does arrive, the ledger records a negative cash entry, the account is restricted to closing trades, and collections begin. Model this explicitly in the interview: it is the most common way a retail broker loses money through its own system.

In the US, a broker must seek best execution under Regulation NMS, which in practice means not trading through a better displayed price on another exchange. The order router keeps the current best bid and offer across venues and chooses where to send each order. Many retail brokers send most orders to wholesale market makers, which often fill at or slightly better than the best displayed price and pay the broker for the flow. That arrangement, payment for order flow, is legal in the US and controversial; mention it neutrally if it comes up.

The router also handles fractional shares. Venues trade whole shares, so the broker fills fractional orders from its own inventory and buys or sells whole shares to rebalance that inventory. That turns the broker into a principal for the fractional part, with its own position limits and risk checks.

At 9:30 Eastern, a large share of users open the app at once. Three things keep the streaming tier upright. First, conflation: the edge server keeps only the latest quote per symbol and sends one frame per user per second, so a symbol that ticks 400 times in a second costs the same as one that ticks once. Second, shared subscriptions: each edge server subscribes once per symbol to the quote bus no matter how many of its users watch it. Third, reconnect pacing: clients reconnect with jittered backoff, and the edge accepts connections at a controlled rate so a server restart does not become a stampede.

Order updates use the same sockets but a different source. The edge consumes order events from Kafka, keyed by account, and forwards only those for its connected users. If the user is not connected, a push notification goes out instead.

US equities settle on T+1: a trade on Monday finalises on Tuesday, when cash and shares actually change hands through the clearing house. Until then, sale proceeds are unsettled. A cash account that buys with unsettled proceeds and sells again before settlement can commit a good faith violation, which the platform must detect and warn about.

Every night, a reconciliation job compares three views: our ledger, the clearing firm's position and cash files, and the bank's records of transfers. Any difference becomes a break that an operations team resolves the next morning, and the job refuses to mark the day closed until breaks are explained. Corporate actions run through the same machinery: a 4-for-1 split multiplies quantities and divides cost basis, a dividend becomes a cash credit on the pay date, and both are applied as ledger events so history stays reproducible.

Markets halt. A single stock can be paused under limit up, limit down bands, and the whole US market pauses if the S&P 500 falls 7%, 13% or 20% in a day. The router must stop sending orders to halted symbols and queue or reject them clearly. A broker also needs its own brakes: in January 2021 clearing house deposit requirements jumped overnight during the meme-stock surge, and several brokers had to restrict buying in a handful of stocks. Build a per-symbol switch that limits trading to closing positions, and design it before you need it.