PracHub
QuestionsPremiumLearningGuidesCheatsheetNEWCoaches
|Home/System Design/Citadel

Design a low-latency trading system

Last updated: Mar 29, 2026

Quick Overview

This question evaluates expertise in designing low-latency, high-determinism electronic trading systems, covering order matching, market data ingestion and publish, partitioning/sharding, persistence for auditability, idempotency, pre-trade risk controls, and operational reliability.

  • hard
  • Citadel
  • System Design
  • Software Engineer

Design a low-latency trading system

Company: Citadel

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Technical Screen

Design an electronic trading platform that supports equities trading with limit and market orders. Specify how you would: ( 1) maintain per-symbol order books and implement a price–time priority matching engine; ( 2) ingest and normalize market data from multiple venues and publish snapshots plus incremental updates with bounded skew; ( 3) expose authenticated APIs for order entry (REST/gRPC) and a low-latency streaming protocol for market data; ( 4) perform pre-trade risk checks (credit/position/price bands), ensure idempotent submissions, and provide exactly-once execution reports; ( 5) achieve P99 end-to-end acknowledgement under 5 ms within one region at 200k orders/second peak, and scale horizontally for bursts; ( 6) persist state with an append-only log or event sourcing, support deterministic replay/backtesting, and meet strict auditability; ( 7) handle partial fills, cancels, mass cancels, auctions, market halts, and symbol pauses; ( 8) design partitioning/sharding of order books, concurrency control inside the matcher, recovery and disaster recovery (RPO ≈ 0, RTO < 1 minute); ( 9) address fault tolerance, time synchronization and clock skew (e.g., PTP), fairness across partitions, backpressure, and flow control; ( 10) define monitoring, SLOs, capacity planning, and strategies to test latency and correctness under failures.

Quick Answer: This question evaluates expertise in designing low-latency, high-determinism electronic trading systems, covering order matching, market data ingestion and publish, partitioning/sharding, persistence for auditability, idempotency, pre-trade risk controls, and operational reliability.

Related Interview Questions

  • Design alerting for application-to-exchange mappings - Citadel (medium)
  • Design a low-latency trading platform - Citadel (hard)
  • Design stock price time-series store and query - Citadel (easy)
  • Discuss queues, NoSQL, and concurrency - Citadel (hard)
Citadel logo
Citadel
Aug 9, 2025, 12:00 AM
Software Engineer
Technical Screen
System Design
36
0

System Design: Low-Latency Electronic Trading Platform (Equities)

You are designing a single-region electronic trading platform (exchange/ATS-like) that supports market and limit orders for equities. Assume co-located clients in the same region and a need for high determinism, strict auditability, and robust failure handling. Design the system to meet the following requirements:

  1. Order Books and Matching
  • Maintain a separate order book per symbol.
  • Implement a price–time priority matching engine (FIFO within each price level).
  1. Market Data Ingest and Publish
  • Ingest and normalize market data from multiple external venues.
  • Publish market data for your platform (snapshots and incremental updates) with bounded skew across symbols/shards.
  1. Client Interfaces
  • Expose authenticated APIs for order entry (REST and/or gRPC).
  • Provide a low-latency streaming protocol for market data.
  1. Risk, Idempotency, and Reports
  • Perform pre-trade risk checks (credit, position, and price bands).
  • Ensure idempotent order submissions.
  • Provide exactly-once execution reports to clients.
  1. Performance and Scale
  • Achieve P99 end-to-end acknowledgement under 5 ms within one region at 200k orders/second peak.
  • Scale horizontally to handle bursts beyond the steady-state peak.
  1. Persistence and Auditability
  • Persist state via an append-only log or event sourcing.
  • Support deterministic replay/backtesting and strict audit trails.
  1. Trading Scenarios
  • Correctly handle partial fills, cancels, mass cancels, auctions, market halts, and symbol pauses.
  1. Partitioning, Concurrency, and Recovery
  • Design partitioning/sharding of order books.
  • Define concurrency control inside the matcher.
  • Support recovery and disaster recovery (RPO ≈ 0, RTO < 1 minute).
  1. Reliability and Fairness
  • Address fault tolerance, time synchronization and clock skew (e.g., PTP), fairness across partitions, backpressure, and flow control.
  1. Operability
  • Define monitoring, SLOs, capacity planning, and strategies to test latency and correctness under failures.

Assumptions:

  • Orders are day-only, with tick size of $0.01; extend as needed.
  • Clients are authenticated institutional participants.
  • One production region with multiple AZs; optional warm-standby region for DR.

Solution

Show

Comments (0)

Sign in to leave a comment

Loading comments...

Browse More Questions

More System Design•More Citadel•More Software Engineer•Citadel Software Engineer•Citadel System Design•Software Engineer System Design
PracHub

Master your tech interviews with 7,500+ real questions from top companies.

Product

  • Questions
  • Learning Tracks
  • Interview Guides
  • Resources
  • Premium
  • For Universities
  • Student Access

Browse

  • By Company
  • By Role
  • By Category
  • Topic Hubs
  • SQL Questions
  • Compare Platforms
  • Discord Community

Support

  • support@prachub.com
  • (916) 541-4762

Legal

  • Privacy Policy
  • Terms of Service
  • About Us

© 2026 PracHub. All rights reserved.