System Design Interview
Retail stock brokerage inspired by Robinhood-style brokers: orders validated against buying power and acknowledged immediately, routed asynchronously over FIX to market makers and exchanges, fills booked to a double-entry ledger, and live quotes streamed over WebSockets. A teaching design.
See why a synchronous order path and per-holding quote lookups can't handle market open.
What was missing: Nothing yet.
Why that's risky: At market open, order volume and quote updates spike together; orders wait on exchange round trips, a retry can submit the same order twice, and the feed competes with users for one server.
What gets added: One server that checks cash, sends each order to the exchange while the user waits, and values portfolios by fetching a quote per holding.
Trade-offs: Simple, but the slowest external system sets the user's latency.
Acknowledge orders fast and safely, and keep money and shares in a ledger that always balances.
What was missing: Orders waited on the exchange, retries could duplicate them, and holdings weren't kept as a ledger.
Why that's risky: Portfolio views read the ledger on every refresh, and prices only update when the user refreshes.
What gets added: An order service that validates, reserves buying power atomically, records the order with an idempotency key and acknowledges it; a routing queue and smart order router that send orders over FIX to market makers or exchanges; and a position updater that books each fill to a double-entry ledger. Market data has its own ingest path into a latest-quotes cache. Like most retail brokers, it routes orders to venues rather than matching them itself.
Trade-offs: Users see 'received' first and the fill a moment later, rather than waiting for both.
Make portfolio views instant and stream prices to the app.
What was missing: Portfolios read the ledger every time, and prices weren't live.
Why that's risky: Users don't find out an order filled unless they look.
What gets added: A positions cache updated on every fill, a quote stream, and quote gateways that hold each app's WebSocket and push updates for watched symbols, conflated to a few per second.
Trade-offs: Conflating quotes drops intermediate ticks the eye can't follow anyway.
Tell users the moment their order fills.
What was missing: Fills were silent.
Why that's risky: There's no way to find an instrument by name, nothing limits runaway clients, and nobody watches routing latency.
What gets added: A fill alerts queue and a notifier that sends a push notification and email for every fill.
Trade-offs: Notifications are sent after booking, so they never announce a fill the ledger doesn't have.
Let users find instruments, contain runaway clients, and watch every step.
What was missing: No search, no per-account limits, no monitoring.
Why that's risky: Remaining risk is regulatory and regional: audit trails and a hot standby region.
What gets added: Instrument search over symbols and company names, rate limits on order submission per account, and monitoring of acknowledgment latency, routing time, fill booking lag, quote freshness and ledger balance checks. End-of-day reconciliation with the clearing firm checks the ledger against the official record.
Trade-offs: Strict order limits can block a legitimate burst; limits are per account and visible to the user.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
