This question evaluates a candidate's competencies in designing scalable, low-latency retail trading systems, covering system architecture, order routing and state management, market data ingestion, cash and position ledger consistency, risk controls, and compliance/observability.
Design an online retail stock trading platform similar to Robinhood. Cover: user onboarding with KYC/AML and funding (e.g., ACH); real‑time balances; market data ingestion and streaming quotes; order submission/validation, risk checks, idempotency, and support for market/limit/stop orders; routing to market makers or exchanges and post‑trade processing with a clearing broker; portfolio and positions with cost basis, PnL, and corporate actions; data model and storage for orders, trades, accounts, and ticks; service decomposition and APIs (sync vs. async), message queues, and event sourcing; consistency and latency guarantees for order state vs. portfolio views; scale and reliability at market open surges, backpressure, HA/DR, and failure modes; observability, auditing/compliance logging, and incident fallbacks (e.g., market data outage); and how you would extend the design to support options or crypto later.
Quick Answer: This question evaluates a candidate's competencies in designing scalable, low-latency retail trading systems, covering system architecture, order routing and state management, market data ingestion, cash and position ledger consistency, risk controls, and compliance/observability.
Design a Retail Stock Trading Platform (Robinhood-like)
Design a mobile-first retail stock trading platform for U.S. equities, similar to Robinhood. The platform partners with a clearing broker for custody and settlement (you are an introducing broker, not self-clearing at launch), sources market data from a third-party vendor (SIP / top-of-book), and routes orders to market makers and exchanges.
At launch you support individual cash accounts only (no margin, no options, no crypto) trading U.S. equities, which settle T+1. Walk through the end-to-end design and be ready to go deep on any of: onboarding & funding, real-time balances and buying power, market-data ingestion and quote streaming, the order lifecycle (validation, risk checks, idempotency, routing, post-trade), portfolio/positions with cost basis and corporate actions, the data model and storage choices, service decomposition and sync-vs-async APIs, consistency and latency guarantees, scale and reliability at market-open surges, observability and compliance/audit, and how you would later extend to options and crypto.
Constraints & Assumptions
State these explicitly; if the interviewer doesn't pin them, propose reasonable numbers and move on.
Scope at launch:
U.S. equities only, individual
cash accounts
(no margin/options/crypto), settling
T+1
. Extended-hours sessions supported; 24/5 trading support.
Custody/settlement:
introducing broker model with a single
clearing broker partner
(not self-clearing).
Market data:
third-party vendor providing
SIP / top-of-book
(NBBO, last sale); no proprietary direct feeds at launch.
Scale (assume and justify):
low single-digit-millions of users;
market-open quote rates can exceed ~100k messages/sec
per region; order submission bursts in the thousands/sec at the open; ~10× baseline burst factor at 9:30 ET.
Latency targets (propose):
order
accept ack < ~50 ms
server-side; fill notification to client within a few hundred ms (vendor/network dependent); quote fan-out coalesced to ~100–250 ms windows.
Invariants:
settled cash must never go negative; no order may reserve buying power it doesn't have; every execution must post to the ledger
exactly once
.
Clarifying Questions to Ask
What's the launch scope — equities only, or do we need options/crypto-ready abstractions from day one (affects how much we over-generalize the OMS and risk engine)?
Are we
self-clearing or using a clearing broker partner
? That changes whether settlement, DTCC/NSCC integration, and capital requirements are in scope.
What buying-power policy do we offer on unsettled funds — strict settled-cash only, or
early/instant deposit availability
with risk limits (which adds credit risk and ACH-return handling)?
What are the regulatory obligations we own vs. inherit from the clearing broker (best execution / Reg NMS, Reg SHO, SEC 17a-4 recordkeeping, FINRA reporting)?
What latency tier are we targeting — "good enough retail" on SIP data, or low-latency with direct feeds and colocated routing (very different cost/complexity)?
Do we need to support fractional shares and DRIP at launch (affects lot/cost-basis math and how the clearing broker aggregates fractional orders)?
What a Strong Answer Covers
A strong answer is judged on breadth across the requirement areas and depth on the trading-critical path. Look for the candidate to address:
Plane separation:
a clear split between the strongly-consistent, low-latency trading/ledger path and the eventually-consistent, read-heavy portfolio/market-data path, with the reasoning made explicit.
Money model:
a double-entry ledger as the source of truth; balances/buying-power derived; buying-power reservation atomic with order acceptance; settled-vs-unsettled and hold semantics.
Order lifecycle:
idempotency, pre-trade risk checks (buying power, halts, fat-finger), a defined state machine, routing via SOR, and post-trade reconciliation with the clearing broker through T+1.
Market data at scale:
vendor session resilience, NBBO/symbol-master maintenance, and client fan-out with coalescing/throttling/backpressure (latest-snapshot-per-window, not every tick).
Data model & storage fit:
OLTP for ledger/OMS, an event log (e.g. Kafka) for order/ledger streams, a time-series/columnar store for ticks; sensible partitioning (OMS by symbol, ledger by account).
Consistency & latency guarantees
stated as explicit numbers and UX states (Pending / Unsettled / Settled), not hand-waved.
Failure handling:
market-data outage, venue/exchange issues, clearing delays, ACH returns — each with a concrete degradation (limit-only, cancel-only, kill switches) and recovery.
Compliance & audit:
immutable/WORM audit trail (SEC 17a-4), surveillance, access controls — treated as first-class, not bolted on.
Extensibility:
what genuinely changes to add options (OPRA/OCC, multi-leg, margin) or crypto (24/7, wallets/custody, no T+1).
Trade-offs named out loud:
clearing-partner vs self-clearing, strong vs eventual consistency, per-symbol vs per-account sharding, SIP vs direct feeds.
Follow-up Questions
A user double-taps "Buy" and the client retries the request after a timeout — walk through exactly how the system guarantees only one order is placed, and what the user sees.
The market-data vendor's feed goes stale mid-session (sequence gaps, no updates). What do you do to the trading path, and what do you show users — and how does this differ for market vs. limit orders?
How do you guarantee a user can never spend the same dollar twice across two orders submitted milliseconds apart on different app instances? Be specific about where the atomicity lives.
A 2-for-1 stock split takes effect overnight. Walk through how positions, lots, cost basis, and any open limit/stop orders are adjusted, and how you keep the ledger and the clearing broker's books in sync.
At market open, quote volume is 10× baseline and the OMS queue is backing up. Describe your backpressure and load-shedding strategy and what you protect at all costs.