Design a Retail Stock Trading Platform with Live Prices and Reliable Order Handling

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. ```hint 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 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. ``` ### 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? ### What a Strong Answer Covers - Requirements that separate the price path from the order path, with latency and correctness targets for each - The order lifecycle as an explicit state machine, with idempotent submission and the cancel-versus-fill race handled - Holds on cash and shares that prevent overspending under concurrency, recorded in an auditable ledger - Reliable venue integration: deduplicated, ordered execution reports and recovery after a disconnect - Fan-out of live prices to many clients with per-symbol subscriptions and conflation - Scaling for the burst at the open, plus failure handling, reconciliation and observability ### 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?