Design a Retail Stock Trading Platform with Live Prices and Reliable Order Handling
MongoDBSoftware Engineer · Onsite
Last updated
A senior system design question asking you to build a retail stock trading platform where users stream live prices, place and cancel market and limit orders, and track positions and cash. It tests order state machines, idempotent submission, buying-power holds, venue integration and real-time price fan-out to many clients.
Design a stock trading platform for retail investors. In the mobile or web app, users watch live prices for the stocks they care about, place buy and sell orders, cancel orders that have not filled yet, and see their positions and cash balance change as their orders execute. Assume the platform is a broker rather than an exchange: it sends orders to external trading venues and receives execution reports back from them.
The report describes the round as a fintech-style design with real-time trading and transaction semantics, so expect the discussion to center on two things: delivering prices quickly to many users, and keeping orders, cash and share balances correct when duplicate requests, partial fills, cancels and crashes interleave. The report names only the system, so the scope below is the standard one for this prompt, written as assumptions.
Constraints and Clarifications
- Order types: market and limit orders for whole shares, good for the trading day. Options, margin, short selling, fractional shares and extended-hours trading are out of scope.
- Venues are black boxes that acknowledge, reject, partially fill, fill and cancel orders, reporting each event asynchronously over a persistent session with sequence numbers.
- Prices arrive from an external market-data provider as a continuous stream of quotes and trades.
- A user must never be able to spend cash or sell shares they do not have, even with several devices submitting orders at once.
- Deposits, withdrawals, settlement, account opening and regulatory reporting are out of scope, except that every change to cash and positions must be auditable.
- Scale and latency targets are not given; agree on them first.
Clarifying Questions
- How many users, concurrent app sessions, tradable symbols and orders per second at the market open should the design handle?
- How fresh must displayed prices be, and does every client need every price change, or is the latest price a few times a second enough?
- Should the app show each partial fill as it happens, or only the final result?
- What happens to an order placed while the market is closed: rejected, or queued for the next open?
- Is it acceptable to respond to the user before the venue has acknowledged the order?
Hints
Hint 1
Decide the invariant first: Before drawing the order path, name the rule about cash and shares that must hold when a user taps Buy twice, a venue reports the same fill twice, or a service crashes between two steps.
Hint 2
Not all real time is equal: Price updates and order updates both feel live to the user, but only one of them can tolerate dropped or merged messages.
Follow-up questions
- If the platform had to match buy and sell orders itself instead of forwarding them, how would the design change?
- The session to a venue drops for half a minute with orders in flight. What do users see, and how does the system recover the true state of each order?
- How would you add price alerts that notify a user when a stock crosses a threshold they set?
- How would you show at the end of the day that your balances agree with what the venues and the clearing firm report?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.