All system design challenges
#58 Matching Engine/Low-Latency

Robinhood Trading

Accept buy and sell orders from millions of retail users, match them fairly in price and time order, and keep every balance exact.

Asked at Robinhood

What is being asked

Design a trading platform. The centre is the order path: risk checks, a matching engine holding the order book, and a record that lets the whole state be rebuilt.

Requirements

Functional

  • Place, cancel and amend market and limit orders.
  • Match orders; report fills; maintain positions and cash balances.
  • Stream market data.

Non-functional

  • Deterministic and fair: price priority, then time priority.
  • Low and predictable latency.
  • No lost or duplicated orders; a full audit trail.

Design

Client appsOrder gateway (auth,validation)Risk check: buyingpowerSequencer (assignsorder of events)Matching engine (oneper symbol group)Event journalMarket data publisherClearing + ledger
Boxes are services; rounded shapes are data stores and queues.
  1. The gateway authenticates and validates an order; a risk check reserves the cash or shares it needs.
  2. A sequencer gives every incoming message a number, creating one agreed order of events.
  3. The matching engine keeps, per symbol, an order book: buy orders sorted by highest price, sell orders by lowest, each price level a queue in arrival order. An incoming order trades against the best opposite prices until it is filled or no longer crosses; the remainder rests in the book.
  4. Every input and every resulting trade is appended to a journal before it is acknowledged.
  5. Trades flow to clearing, which updates positions and the cash ledger.

Key decisions and trade-offs

  • Single-threaded matching per symbol. No locks and a fully deterministic result; replaying the journal reproduces the exact state, which is also how a standby stays in step and how recovery works.
  • In memory, with the journal as durability. A database in the hot path would be far too slow.
  • Shard by symbol. Orders for different symbols never interact, so engines scale horizontally.
  • Retail platforms often route orders to exchanges or market makers instead of matching internally; the same gateway, risk and ledger design applies, with an order router in place of the engine.

Follow-up questions

  • How do you guarantee an order is processed once if the gateway retries?
  • What happens during a market open when volume is fifty times normal?
  • How would you support stop orders?
  • How do you prove afterwards that two orders were handled in the right sequence?
Log in to tick off the challenges you have worked through. Log in