Katkat

Design a low-latency trading platform

CitadelSoftware Engineer · Onsite

Last updated

This question tests the ability to architect a high-throughput, sub-millisecond trading system while balancing strict deterministic latency requirements with necessary safety checks.

Problem Statement

Design a high-frequency trading (HFT) platform capable of ingesting market data from multiple exchanges, executing automated strategies, and managing orders. The system must operate with microsecond-level latency while maintaining rigorous pre-trade risk controls.

Functional Requirements

  1. Market Data Feed Handler: Consume UDP multicast feeds from multiple exchanges, normalize data, and publish it to an internal messaging bus.
  2. Strategy Engine: Subscribe to normalized market data, execute trading logic based on current state, and emit order signals.
  3. Order Management System (OMS): Manage the lifecycle of orders, track fills, and handle cancellations/modifications.
  4. Pre-trade Risk Engine: Validate every outgoing order against limits (e.g., maximum position size, daily loss limit, fat-finger checks) before sending to the exchange.

Non-Functional Requirements

  • Latency: End-to-end latency from market data packet arrival to order gateway departure must be under 50 microseconds.
  • Throughput: Support spikes of up to 1 million messages per second.
  • Determinism: Minimize jitter caused by garbage collection or thread context switching.
  • Reliability: The system must be fault-tolerant; a single component failure should not result in an unauthorized market position.

Expected Deliverables

  • A high-level system architecture diagram (described in text).
  • Selection of transport protocols and data serialization formats (e.g., SBE, Protobuf, shared memory).
  • Discussion on how to minimize 'stop-the-world' latency spikes.
  • A strategy for how risk checks can be performed without significantly bloating the hot path.
  • Approaches for logging and monitoring without impacting performance.

Hints

Hint 1

Consider the trade-offs between using kernel-bypass networking (like Solarflare/OpenOnload) versus standard OS network stacks.

Hint 2

Think about memory layout and CPU pinning to avoid cache misses and thread migrations.

Hint 3

Explore how to implement risk checks using an 'inline' vs 'sidecar' architecture and how pre-calculated risk limits can reduce latency.

Follow-up questions

  • How would you ensure that your trading engine is 'deterministic' so that you can replay a day of trading exactly as it happened for backtesting?
  • If the exchange feed experiences a burst of volume that exceeds our processing capacity, how should the system degrade gracefully?
  • How do you design for zero-copy data passing between the strategy engine and the order gateway?