Skip to content

Ibkr trading platform

Design a scalable, ultra-low-latency trading platform for an Interactive Brokers–scale online brokerage that supports multi-asset electronic trading, real-time market data, risk management, and order lifecycle management across global exchanges.

The system must handle millions of concurrent users, real-time price feeds, deterministic order execution, and strict regulatory compliance while maintaining sub-millisecond internal latency and five-nines availability.

You are expected to design this as if it were going into production at Interactive Brokers scale.

Functional Requirements

Your design must support:

  1. Order Management

  2. Order types:

    • Market, Limit, Stop, Stop-Limit, Trailing Stop
    • Bracket orders (parent + take-profit + stop-loss)
    • Algorithmic orders (TWAP, VWAP, Iceberg)

    • Order lifecycle:

    • Submit → Validate → Route → Acknowledge → Fill/Partial Fill → Complete/Cancel

    • Modifications and cancellations in-flight
    • Support for multi-leg options orders

  3. Market Data Distribution

  4. Real-time streaming quotes (Level 1 and Level 2 / depth-of-book)

  5. Tick-by-tick trade data
  6. Historical OHLCV bars (1s to 1M granularity)
  7. Multi-exchange consolidated feed

  8. Subscription-based delivery (users subscribe to specific symbols)

  9. Multi-Asset Support

  10. Equities, Options, Futures, Forex, Fixed Income, Crypto

  11. Cross-asset margin and risk aggregation

  12. Exchange-specific protocol adapters (FIX, ITCH, proprietary)

  13. Account & Portfolio Management

  14. Real-time P&L, margin, and buying power

  15. Position tracking across asset classes
  16. Multi-currency support with real-time FX conversion

  17. Account hierarchies (advisor → sub-accounts)

  18. Risk & Compliance

  19. Pre-trade risk checks (margin, position limits, concentration)

  20. Real-time margin computation (TIMS / portfolio margining)
  21. Regulatory reporting (SEC, FINRA, MiFID II)

  22. Trade surveillance and anomaly detection

  23. APIs

  24. Order submission / modification / cancellation API

  25. Market data streaming API (WebSocket + REST fallback)
  26. Account / portfolio / positions API
  27. Historical data API

Non-Functional Requirements

Your system must meet the following constraints:

  1. Scale

  2. Millions of registered accounts, hundreds of thousands concurrent during market hours

  3. Tens of millions of orders per day

  4. Billions of market data messages per day across all exchanges

  5. Latency

  6. Order-to-exchange (internal path): P99 ≤ 1 ms

  7. Market data tick-to-client: P99 ≤ 5 ms

  8. API response for account queries: P99 ≤ 100 ms

  9. Throughput

  10. Market data ingestion: 10M+ messages/sec sustained

  11. Order processing: 100K+ orders/sec peak

  12. Market data fan-out: 1M+ subscriptions served concurrently

  13. Availability

  14. ≥ 99.999% uptime during market hours

  15. Zero data loss for order and trade records

  16. Graceful degradation during exchange outages

  17. Consistency

  18. Strict ordering for order lifecycle events per account

  19. Exactly-once semantics for order execution

  20. Eventual consistency acceptable for P&L display (< 1s lag)

  21. Durability & Auditability

  22. Full audit trail for every order event (immutable log)

  23. 7-year retention for regulatory compliance
  24. Point-in-time recovery for positions and balances

What You Should Deliver

Provide a practical, production-oriented design that includes:

  1. Requirement clarification & assumptions

  2. High-level architecture

  3. Core services (Gateway, Order Management, Matching/Routing, Market Data, Risk, Settlement)

  4. Data flow (order submission → risk check → routing → exchange → fill → settlement)

  5. Order management system

  6. Order state machine

  7. Smart order routing (SOR)
  8. Deterministic processing guarantees

  9. In-memory vs persistent state

  10. Market data architecture

  11. Feed handlers and normalization

  12. Fan-out strategy to clients
  13. Conflation and throttling for slow consumers

  14. Historical data storage and retrieval

  15. Risk engine design

  16. Pre-trade vs real-time vs end-of-day risk

  17. Margin computation approach

  18. Position aggregation across asset classes

  19. Data storage choices

  20. Hot path (in-memory / LMAX-style)

  21. Warm path (time-series for market data)
  22. Cold path (archive for compliance)

  23. Event sourcing and audit log

  24. Scalability strategy

  25. Partitioning by account / symbol / exchange

  26. Horizontal scaling of stateless services

  27. Market data multicast and shared-memory architectures

  28. Failure handling

  29. Exchange connectivity failover

  30. Order state recovery after crash
  31. Split-brain prevention

  32. Circuit breakers and backpressure

  33. Rough capacity estimates

  34. Orders/day, market data messages/sec

  35. Storage for tick data and audit logs

  36. Network bandwidth requirements

  37. Trade-offs

    • Latency vs consistency decisions
    • In-memory vs durable state boundaries
    • Build vs buy for matching/routing
    • What is sacrificed for regulatory compliance

Expectations

  • Be concrete (mention specific patterns: event sourcing, LMAX Disruptor, FIX protocol, kernel bypass, multicast)
  • Design for determinism — trading systems cannot tolerate non-deterministic behavior
  • Address regulatory requirements as first-class concerns, not afterthoughts
  • Prefer simple, battle-tested designs over clever optimizations
  • Assume this system handles real money — correctness trumps performance
  • Assume this system will be maintained by hundreds of engineers for 20+ years

Interview Kit

Read first: Solution incl. Security section · Transactions · Consensus §17.6 GitHub failover · Resilience

Curveballs. The interviewer changes one thing mid-design. The hint in italics is what a strong answer reaches for:

  1. A client retries POST /orders after a timeout and buys twice. (Mandatory idempotency keys with fingerprints.)
  2. A change to the order API lets a user submit orders for another account ID. (Entitlement check on the body's account_id, IDOR tests.)
  3. The primary region's network blips for 43 s. Should the OMS fail over? (Never promote a replica missing acknowledged writes. Manual cross-region failover.)
  4. Market open sends 50× order volume in the first second. What do you reject, and how?

Must answer (security, privacy, operations):

  • Account-takeover defenses: phishing-resistant MFA, step-up for trading and withdrawals
  • Retention conflict: SEC record-keeping vs. GDPR erasure, and how you resolve it

Phase it (MVP → Growth → Scale): MVP: a monolith OMS with Postgres, one broker connection, pre-trade risk checks. Growth: Kafka event log, separate risk engine, market-data fan-out. Scale: per-venue gateways, multi-region, surveillance at scale.

Score yourself with the rubric.