Design a low-latency trading platform
CitadelSoftware Engineer · OnsiteLast 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
- Market Data Feed Handler: Consume UDP multicast feeds from multiple exchanges, normalize data, and publish it to an internal messaging bus.
- Strategy Engine: Subscribe to normalized market data, execute trading logic based on current state, and emit order signals.
- Order Management System (OMS): Manage the lifecycle of orders, track fills, and handle cancellations/modifications.
- 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?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.