Design Robinhood
Understanding the Problem
Robinhood is a commission-free trading platform for stocks, ETFs, options, and cryptocurrencies. It features real-time market data and basic order management. Robinhood isn't an exchange in its own right, but rather a stock broker; it routes trades through market makers ("exchanges") and is compensated by those exchanges via payment for order flow .
Background: Financial Markets
There's some basic financial terms to understand before jumping into this design:
- Symbol : An abbreviation used to uniquely identify a stock (e.g.
META,AAPL). Also known as a "ticker". - Order : An order to buy or sell a stock. Can be a market order or a limit order .
- Market Order : An order to trigger immediate purchase or sale of a stock at the current market price. Has no price target and just specifies a number of shares.
- Limit Order : An order to purchase or sell a stock at a specified price. Specifies a number of shares and a target price, and can sit on an exchange waiting to be filled or cancelled by the original creator of the order.
Outside of the above financial details, it's worth understanding the responsibilities of Robinhood as a business / system. Robinhood is a brokerage and interfaces with external entities that actually manage order filling / cancellation. This means that we're building a brokerage system that facilitates customer orders and provides a customer stock data. We are not building an exchange.
For the purposes of this problem, we can assume Robinhood is interfacing with an "exchange" that has the following capabilities:
- Order Processing : Synchronously places orders and cancels orders via request/response API.
- Trade Feed : Offers subscribing to a trade feed for symbols. "Pushes" data to the client every time a trade occurs, including the symbol, price per share, number of shares, and the
orderId.
For this interview, the interviewer is offering up an external API (the exchange) to aid in building the system. As a candidate, it's in your best interest to briefly clarify the exchange interface (APIs, both synchronous and asynchronous) so you have an idea of the tools at your disposal. Typically, the assumptions you make about the interface have broad consequences in your design, so it's a good idea to align with the interviewer on the details.
Functional Requirements
Core Requirements
- Users can see live prices of stocks.
- Users can manage orders for stocks (market / limit orders, create / cancel orders).
Below the line (out of scope)
- Users can trade outside of market hours.
- Users can trade ETFs, options, crypto.
- Users can see the order book in real time.
This question focuses on stock viewing and ordering. It excludes advanced trading behaviors and doesn't primarily involve viewing historical stock or portfolio data. If you're unsure what features to focus on for a feature-rich app like Robinhood or similar, have some brief back and forth with the interviewer to figure out what part of the system they care the most about.
Real-time stock price updates are a perfect example of the real-time updates pattern. Here we use Server Sent Events (SSE) to establish persistent connections that allow our servers to push live price changes to clients instantly. This approach handles the networking fundamentals of real-time communication while ensuring users see current market prices without the inefficiency of constant polling.