Design Robinhood: A Stock Trading App with Live Prices and Safe Orders

Users need to see quotes update live for whatever stocks are visible, whether that is a watchlist or a single stock's detail page. They can place buy or sell orders as market orders, which execute at the best available price, or as limit orders, which only execute at a chosen price or better.

Users can also cancel an order that has not yet been filled, and track every order's status alongside the portfolio positions it affects. We explicitly do not build an order-matching engine; that is the exchange's job. Funding the account through deposits is also excluded. Drawing that line clearly tells the interviewer you understand where the brokerage's responsibility ends and the market's begins.

Price updates should reach the screen within about 200 ms of the change, which is fast enough to feel live without demanding the latency of a professional trading terminal. Orders demand strong consistency: an order accepted by the app must never vanish and must never be executed twice, even when clients retry or servers crash mid-request.

Availability during market hours is critical, targeting 99.99%. An outage during a market sell-off is not just inconvenient; customers who cannot exit positions can lose real money. Finally, traffic is spiky. The opening bell at 9:30 AM and major news events produce sharp bursts in both orders and price viewers, so capacity must be planned for the peak, not the average.

Assume 20 million daily active users placing around 5 million orders a day. Because trading is concentrated into a 6.5-hour session, that averages roughly 200 orders per second, with bursts into the low thousands right at the open. That order rate is modest; a well-tuned relational database handles it easily.

The price side is where the numbers explode. Assume 2 million users have a price screen open at peak, each holding a live connection and viewing about 5 symbols, with one update per symbol per second. That is around 10 million outbound price messages every second. The lesson is clear: orders need correctness more than throughput, while price delivery is a massive fan-out problem that needs its own infrastructure.

The model has four entities: User, Symbol with its latest Quote, Order, and Position (the shares a user currently owns). Keeping Position separate from Order lets the portfolio be updated only when fills actually arrive.

Prices flow over a WebSocket at /prices; the client sends the list of symbols it wants, such as AAPL and TSLA, and receives a stream of symbol, price and timestamp messages. POST /orders takes symbol, side, quantity, type, an optional limit price and a client-generated idempotency key, returning an order ID in PENDING. DELETE /orders/{order_id} returns CANCEL_REQUESTED rather than cancelled, because only the exchange can confirm a cancel actually happened before a fill. GET /orders?status=open lists open orders with their filled quantity.

The architecture has two independent lanes. On the order lane, clients go through an API gateway for authentication and rate limiting to an order service. That service checks buying power or share holdings, writes the order to Postgres as PENDING, and passes it to an exchange gateway. The gateway is the single component that holds a FIX session with the exchange, sends orders, and receives execution reports that it writes back as status changes and fills.

On the price lane, a market data feed from the exchange or a vendor streams ticks into a price service, which publishes each one to a Redis pub/sub channel per symbol. A fleet of push servers listens to the channels their connected users care about and forwards updates over WebSockets. Because the lanes share nothing on the hot path, a flood of price ticks during a volatile session cannot delay someone trying to sell.

Polling every second is the simplest option, but quotes go stale between requests and millions of clients generate an enormous volume of mostly redundant calls. Server-Sent Events push data over plain HTTP and suit one-way streams, yet changing the set of watched symbols means a new request each time a user scrolls to a different stock.

WebSockets win because a single long-lived connection can carry both directions: the client adjusts its symbol list on the fly and the server streams updates back. Fan-out is efficient because each push server joins a symbol's Redis channel once, regardless of how many local users watch it, then copies each tick to those connections in memory.

Conflation keeps the load sane. If a symbol changes fifty times in one second, only the latest value is sent, at most once per second, which saves bandwidth and battery without hurting a retail user. When a push server fails, its clients reconnect elsewhere, restate their symbol list and receive a fresh snapshot, so nothing needs to be persisted per connection.

When a user taps Buy, the order service first verifies buying power and places a hold on the funds (or, for a sell, on the shares). Without that hold, a user with $1,000 could fire off two $1,000 orders in quick succession and overspend. The order is then written as PENDING before anything leaves our system, so even if a server dies a moment later there is a durable record to recover from.

The exchange gateway transmits it as a FIX message carrying a client order ID that we generate. From there, the order behaves as a state machine: PENDING to SUBMITTED, then PARTIAL and FILLED, or REJECTED or CANCELED. Execution reports only ever advance it. On each fill, the user's position is increased and any unused portion of the hold is released, for example when a limit buy executes below its limit. Finally, a push notification goes out and the app refreshes the portfolio.

Duplicate protection starts on the device. The app generates an idempotency key per order and reuses it on any retry, so a request repeated after a timeout returns the original order instead of creating another. The gateway applies the same idea outward: a resend always carries the same client order ID, and the exchange rejects duplicate IDs, so one order can never fill twice.

Crash recovery is cautious by design. A restarted gateway first asks the exchange where each outstanding order stands, then decides what, if anything, needs resending. Execution reports land in Kafka, a durable log, and consumers record each execution ID they have applied, so replaying the log after a failure does not add shares twice. As a final backstop, a nightly job compares our orders and positions to the official broker reports and corrects any discrepancy.

Choosing WebSockets over SSE buys flexible two-way symbol management but brings stateful servers that need connection draining and reconnect handling. Conflation dramatically cuts traffic, at the cost of users not seeing every single tick, which is acceptable for a consumer app.

The design deliberately mixes consistency models: strict for orders and positions, relaxed for prices. Paying for strong guarantees only where money moves keeps the price lane cheap and fast. Reserving funds up front prevents overspending, though the held cash is unavailable until the order fills or is cancelled. The short version: prices can be quick and slightly lossy, but every order must be exact.