Robinhood

Interview scope and guarantees

Submit and cancel orders, display order status, show positions and buying power, and ingest external execution reports. This is an interview model, not a description of a broker’s implementation. Market data can lag; accepting an order must not over-reserve cash or securities.

Capacity worksheet

Assume 1 million users open the app at market start and 5% submit over one minute: about 833 order submissions/s. Quotes can update many times per second for popular symbols, so do not persist and fan out every tick through the transactional order path.

Concrete API contract

POST /orders {clientOrderId,symbol,side,quantity,type,limitPrice?}
POST /orders/{id}/cancel -> {cancelRequestId}
GET /orders/{id}
GET /accounts/{id}/positions

Data model and access paths

orders(id PK,account_id,client_order_id,request_hash,state,filled_qty,version); UNIQUE(account_id,client_order_id)
reservations(order_id UNIQUE,asset,quantity,state)
executions(venue,execution_id,order_id,qty,price); UNIQUE(venue,execution_id)
ledger_entries(transaction_id,line,account,asset,delta); PK(transaction_id,line)

Evolve a solution and explain each change

Figure — Three architecture decisions for Robinhood, including the pressure each introduces.

Step 1: Accept an order safely

Validate account and instrument; reserve the required buying power or position. A cached balance can permit overspending.

Step 2: Route and reconcile

Persist an order identity before sending to the execution venue and reconcile acknowledgements. A route timeout can occur after venue acceptance.

Step 3: Account for fills

Apply immutable fill identities to a ledger with partial-fill and cancellation states. Cancellation requests can race with additional fills.

Responsibility overview

Figure — Connected responsibilities for Robinhood. Trace the authoritative and derived paths separately.

Worked end-to-end scenario

A customer submits a limit buy for ten shares. The service reserves funds according to a conservative price/fee policy and records order o17 before routing. The venue accepts but the response is lost, so the service queries by the stable client order identity rather than placing a second order. Four shares fill before cancellation. The fill updates position and cash accounting exactly once using its venue fill ID; cancellation can only stop the remaining six if the venue confirms it. Release unused reservation after the final reconciled outcome. Quotes displayed in the app are not the authoritative execution price.

Why these access paths matter

Order lookup uses account and order identity; fills use a unique venue/execution identifier. Keep reservation and ledger transitions transactional within the account authority. Market-data projections and trading admission are separate systems. Use exact amounts and instrument quantity rules; a generic floating-point balance is not adequate accounting.

Build the baseline first

1. Order request → risk/reservation transaction → routing outbox.
2. Venue report → deduplicated execution → ledger.
3. Position projection → account view.

Evolve the design under load

1. Market-data stream → symbol subscriptions → quote gateways.
2. Account-key command routing → ordered risk decisions.
3. Reconciliation feed → discrepancies → operations queue.

Defend the hardest decision

Reserve buying power before routing a buy order. A market order needs a bounded risk policy because its final price is not known. Partial fills release or consume reservations incrementally and create immutable execution records. A cancel request is not a cancellation acknowledgement: a fill may win the race at the venue. Model pending-cancel explicitly and process authoritative execution reports.

Failure and recovery analysis

A routing timeout leaves uncertainty about whether the venue received the order. Retry with the same external client order ID if supported, query status and reconcile. Never create a fresh order ID just to escape the timeout. Duplicate fills must be rejected by venue execution identity; a local sequence alone is insufficient across reconnects.

Security and privacy boundary

Use strong account authorization, audit administrative actions, isolate market data from money movement, and never log trading credentials.

Interview follow-ups with reasoning

Question: How do you rebuild positions?

Question: How do you handle out-of-order reports?

Question: What if quotes stop?

Operate and verify the design

Uncertain order age, execution dedup hits, reservation discrepancies and venue-report lag.

Race a cancel acknowledgement with a partial fill and verify positions and reserved buying power.

A second scenario to test transfer

An order for 10 shares receives a fill for 4, then a timeout, then a second report for the same fill. Deduplicate the external report ID and apply only four shares. A later fill of 6 completes the order. The portfolio view advances from ledger events and reports its watermark; order accepted and order filled remain separate user-visible states.

An order submission times out and the client retries. Then one partial fill report is delivered twice. How many orders and position changes should exist?

Compare alternatives

A design-changing exercise

A cancel request returns successfully from the API. Does that prove there will be no further fill?

Design workshop: reserve buying power and apply fills once

Core scope is limit-order admission, venue routing, partial fills/cancel and portfolio display. Margin, options, tax and regulatory compliance are outside this interview baseline. This is a hypothetical software design, not investment advice or a representation of a broker's actual system. Choose exact quantity/currency arithmetic, no negative reserved buying power and quote freshness explicitly displayed.

Orders are unique(account_id,client_order_id); changing order parameters under the same identity returns conflict. Executions are unique(venue,execution_id), since a venue-local ID is not automatically globally unique. A cash account with $1,000 placing ten shares at a $50 limit and a $2 maximum fee reserves $502, leaving $498 available. A four-share fill at $49 consumes $196; remaining six shares need $300 plus the unspent fee reserve under the fee policy. Track reserved, available and settled/unsettled balances separately.

Figure — Cash and reservation example with no fee charged yet.

An illustrative double-entry cash transfer for the $196 fill debits a customer-funds liability and credits a broker clearing payable by $196. An independent share ledger records +4 shares in customer holdings and −4 from the clearing allocation in the same asset. These balance per asset; dollars and shares cannot be summed as if the same unit. Settlement and fees append further entries. The account authority transaction checks reservation, inserts the unique execution, updates order filled quantity and posts the fill once.

Figure — Fill races with cancellation.

State progression is created→route_pending→acknowledged→partially_filled→filled, with cancel_pending orthogonal to outstanding quantity. A cancel request is not a venue-confirmed cancel; more fills can arrive meanwhile. Venue reports can repeat and be out of order. Persist report identity and cumulative/individual quantity semantics; missing sequence gaps trigger reconciliation. A trade bust/correction appends reversing/correcting execution-linked entries, never edits the original ledger history invisibly.

Quotes arrive on a separate market-data stream keyed by instrument/venue sequence, with snapshot+suffix recovery. Gateways fan out subscriptions and bound slow-client buffers. A portfolio view displays its applied ledger watermark and quote timestamp; stale quotes cannot become authoritative buying-power updates. Trading admission still checks account funds and declared price/limit rules under its authority.

At one million quote subscribers for a popular instrument, fanout bandwidth can exceed order-write load. Batch quote display under a stated freshness budget while preserving execution events durably. Isolate the routing/account path from optional chart queries. Monitor venue sequence gaps, reserve reconciliation, unmatched fills, cancel age and quote age separately.

Exercise: The same four-share fill is reported twice after a cancel request. How many position changes occur?

Technical references

Provider idempotency contract example.

PostgreSQL transaction isolation and concurrent updates.