Sequence 10 - Quant 项目专项深挖：系统设计、风控、低延迟和面试回答

这一页把 /Users/fengwenxuan/Desktop/startup-project/quant/ 下的项目整理成可以面试讲述的系统设计。它不是金融收益展示，而是用 quant 项目证明你具备：

1. 高性能事件驱动系统设计能力
2. hot path / low latency / throughput / P99 意识
3. 风控、熔断、审计、可观测性意识
4. C++/TypeScript/Python 多语言系统工程经验
5. 将策略逻辑、执行系统、数据系统、风控系统拆开的架构能力

1. 先回答：项目深挖是不是应该单独写 sequence？

是。现在 sequence-03 应该只做 CV 项目总索引和讲解模板；真正的项目细节应该拆成单独 sequence。原因：

sequence-03: 告诉你有哪些项目、每个项目和 JD 怎么连接。
sequence-10: 深挖 quant 项目，包括系统设计、数据路径、风控、低延迟、Q&A。
后续应该继续拆：
  sequence-12: AI 风控 / LLM 平台专项
  sequence-13: GPU / Vulkan / WebGPU / 3D asset workflow 专项
  sequence-14: 高并发通信系统专项
  sequence-15: ATE / HW-SW diagnostics 专项

这样你复习时不会在一个超长文档里迷路。面试官问项目时，你也能按项目切换，而不是按零散技术点回答。

2. Quant 项目总览

flowchart TB
    Quant["Quant Project Family"] --> Poly["Polymarket Quant"]
    Quant --> Meme["Meme Quant"]
    Quant --> Cefi["CeFi Cpp Low Latency Infra"]
    Quant --> Arbx["Cross Exchange Arbitrage App"]
    Quant --> LP["CEX Unreal LP and Market Making"]

    Poly --> PolySys["Prediction Market OMS Hedging EIP712 Risk"]
    Meme --> MemeSys["Smart Money Archive Backtest MEV Kill Switch"]
    Cefi --> CppSys["Cpp Market Data Gateway Order Router Pre Trade Risk"]
    Arbx --> ArbSys["Market Data Collector Opportunity Analyzer Executor"]
    LP --> LPSys["Quoting Hedge Signal Risk OMS"]

    PolySys --> JD["JD Transferable System Skills"]
    MemeSys --> JD
    CppSys --> JD
    ArbSys --> JD
    LPSys --> JD

    JD --> Perf["Performance Profiling Benchmark"]
    JD --> Arch["Architecture Prototype Roadmap"]
    JD --> Reliability["Risk Observability Failure Handling"]
    JD --> DataPath["Data Path Control Path Thinking"]

3. 和 NVIDIA JD 的关系

这个项目不是直接做 UCX/NIXL/GPUNetIO，也不是 GPU kernel 项目。不要硬说它等价于 AI networking。正确连接方式是：

英文回答：

The quant projects are not a direct replacement for UCX or NIXL experience. I would use them to demonstrate my systems thinking: event-driven data paths, hot-path latency control, pre-trade risk gates, order-state machines, replay/backtest validation, observability, and kill-switch design. Those are transferable to AI infrastructure because large-scale inference systems also require clear data paths, measurable bottlenecks, safety controls, and evidence-driven optimization.

3.1 Quant 项目推荐讲解结构：中文一段 + English 一段

中文项目讲法：

Quant 项目不能讲成“我做交易赚钱”，而要讲成 performance-sensitive systems。数据来源包括 exchange market data、order book/ticker、wallet/archive data、strategy config、risk config、execution/fill events 和 historical replay data。数据路径通常是 market data -> normalize/order book -> strategy signal -> pre-trade risk -> order router/execution -> fill update -> position/PnL/accounting -> replay/backtest/report。

我做这些项目的重点是把交易系统拆成 data path、control path 和 safety path。Data path 负责行情、信号、下单、成交回报；control path 负责配置、模式切换、healthcheck、paper/live 隔离；safety path 负责 balance check、position limit、open-order limit、daily loss limit、liquidity/slippage check、kill switch 和 reconciliation。指标上看 hot-path latency、P95/P99、queue depth、risk rejection rate、fill/reject rate、PnL/accounting consistency、replay consistency 和 benchmark regression。

具体数值上，Polymarket binary market 可以讲一个明确条件：YES + NO 到期总价值理论上是 1，所以策略机会必须满足 `Cost(YES) + Cost(NO) < 0.99` 这类成本约束。低延迟部分如果没有正式生产 benchmark，不要编固定微秒数字；可以说系统按 P95/P99、throughput、risk-check latency、order-routing latency 和 regression gate 来设计。

English project story:

I would not present the quant projects as trading-profit stories. I would present them as performance-sensitive systems. The data sources include exchange market data, order books and tickers, wallet or archive data, strategy configuration, risk configuration, execution and fill events, and historical replay data. The data path is usually market data, normalization or order book, strategy signal, pre-trade risk, order router or execution, fill update, position and PnL accounting, and replay or backtest reporting.

My focus was decomposing trading systems into a data path, a control path, and a safety path. The data path handles market data, signals, orders, and fills. The control path handles configuration, mode switching, health checks, and paper/live separation. The safety path handles balance checks, position limits, open-order limits, daily-loss limits, liquidity or slippage checks, kill switches, and reconciliation. The metrics include hot-path latency, P95/P99, queue depth, risk-rejection rate, fill or reject rate, PnL/accounting consistency, replay consistency, and benchmark regression.

For concrete numbers, the Polymarket-style binary market has a clear condition: YES plus NO settles to one dollar in total, so the opportunity must satisfy a cost constraint such as `Cost(YES) + Cost(NO) < 0.99`. For low-latency components, if I do not have a formal production benchmark, I should not invent microsecond numbers. I would say the system is designed around P95/P99, throughput, risk-check latency, order-routing latency, and regression gates.

3.2 CV 实际案例：OKX 交易接入 / OMS / 撮合链路 / 网络路径怎么讲

这一段是按你 CV 里的真实经历来组织：OKX 的 Wallet / Infrastructure / DEX / Trading 相关 performance-sensitive production paths、gRPC/Kafka 通信路径、routing、queueing、backpressure、tail latency，以及 ~/Desktop/startup-project/quant/cex-unreal-lp/kucoin-okx-quant.md 里的交易接入架构准备。注意边界：不要说“我 owning 过 OKX 撮合引擎核心”，而要说“我做过交易相关生产路径、性能和稳定性治理，能按 Gateway/Risk/OMS/Adapter/Matching/Report 这条链路分析问题”。

中文项目讲法：

我在 OKX 的经历和 quant 项目的连接点，不是单纯策略收益，而是交易系统路径。CV 里的实际口径是：我参与 Wallet、Infrastructure、DEX、Trading 相关 performance-sensitive production paths，做 performance、stability、correctness validation、regression-risk governance，也调查过 gRPC/Kafka 通信路径、routing、queueing、backpressure 和 latency failure modes。

如果面试官问交易系统，我会按交易接入链路讲：Client/Strategy -> Gateway -> Session/Auth/RateLimit -> Pre-trade Risk -> OMS/Sequencer -> Order Router -> Venue Adapter 或 Matching Engine -> Execution Report -> Client，同时旁路有 Journal、Kafka、DB、Reconcile、Audit、Metrics。这里的关键不是某一个 API，而是订单状态一致性、回报不丢、断线可恢复、tail latency 可解释。

网络上我会重点讲四类：第一是外部客户或策略到 Gateway 的 TCP/WebSocket/FIX/Binary session；第二是内部 Gateway/Risk/OMS/Adapter 之间的 RPC、queue 或 event bus；第三是 Kafka/journal/reconcile 这类冷路径，不能阻塞热路径；第四是行情和订单回报 WebSocket，要处理慢消费者、断线重连、sequence gap、snapshot rebuild 和补偿。

English project story:

The connection between my OKX experience and the quant projects is not trading profit. It is the trading-system path. The accurate CV framing is that I worked on performance-sensitive production paths across Wallet, Infrastructure, DEX, and Trading systems, focusing on performance, stability, correctness validation, and regression-risk governance. I also investigated gRPC/Kafka communication paths, routing, queueing, backpressure, and latency-related failure modes.

If asked about trading systems, I would describe the trading access path: client or strategy, gateway, session/auth/rate limit, pre-trade risk, OMS or sequencer, order router, venue adapter or matching engine, execution report, and client feedback. The side path includes journal, Kafka, database, reconciliation, audit, and metrics. The key problems are not a single API; they are order-state consistency, no lost execution reports, disconnect recovery, and explainable tail latency.

On networking, I would separate four paths. First, the external client or strategy to gateway path, such as TCP, WebSocket, FIX, or binary session. Second, the internal gateway/risk/OMS/adapter path, usually RPC, queues, or event bus. Third, the cold path such as Kafka, journal, and reconciliation, which must not block the hot path. Fourth, market data and private order WebSocket paths, where the system must handle slow consumers, reconnects, sequence gaps, snapshot rebuilds, and compensation.

3.2.1 交易接入总架构 / Trading access architecture

flowchart TB
    Client["KA Client Strategy Maker"] --> Gateway["Gateway FIX Binary WS REST"]
    Gateway --> Session["Session Auth Rate Limit"]
    Session --> Risk["Pre Trade Risk"]
    Risk --> OMS["OMS Sequencer Idempotency"]
    OMS --> Router["Order Router"]
    Router --> Adapter["Venue Adapter"]
    Adapter --> Venue["Exchange or Matching Engine"]
    Venue --> Adapter
    Adapter --> OMS
    OMS --> Report["Execution Report"]
    Report --> Client

    OMS --> Journal["Local Journal WAL"]
    Journal --> Kafka["Kafka Event Stream"]
    Kafka --> DB["DB Reconcile Audit"]
    DB --> Metrics["Metrics Latency Report"]

中文解释：

这个架构里，热路径是 Gateway -> Risk -> OMS -> Router -> Adapter -> Venue -> Report。热路径不能查 DB、不能等待 Kafka、不能同步写大日志、不能远程读取配置。冷路径才做 journal、Kafka、DB、reconcile、audit 和报表。这样客户说订单慢时，才能按 order_id 给出分段 latency breakdown。

English explanation:

In this architecture, the hot path is gateway, risk, OMS, router, adapter, venue, and report. The hot path should not query a database, wait for Kafka, synchronously write heavy logs, or remotely fetch configuration. The cold path handles journal, Kafka, database, reconciliation, audit, and reporting. This makes it possible to explain latency by order id when a client reports a slow order.

3.2.2 撮合/订单状态机怎么讲 / Matching and order-state-machine discussion

中文：

如果面试官问撮合引擎，我不会夸大说我 owning 过核心撮合。我会从系统不变量讲：订单进入 sequencer 后必须有确定顺序；同一 order_id 或 account/symbol shard 最好 single writer；状态机要处理 new、ack、partial fill、fill、cancel pending、cancel success、cancel reject、timeout unknown、reconcile。关键不变量是 filled_qty 只能增加、leaves_qty 不能小于 0、终态不能回退、同一 fill_id 不能重复入账、同一 clOrdId 不能创建两笔订单。

English:

If the interviewer asks about a matching engine, I would not overstate ownership of a core exchange matching engine. I would discuss the system invariants. Once an order enters a sequencer, it needs deterministic ordering. The same order id or account/symbol shard should preferably have a single writer. The state machine must handle new, ack, partial fill, fill, pending cancel, cancel success, cancel reject, timeout unknown, and reconciliation. Key invariants are: filled quantity only increases, leaves quantity cannot be negative, terminal states cannot roll back, the same fill id cannot be booked twice, and the same client order id cannot create two independent orders.

3.2.3 网络与延迟证据链 / Networking and latency evidence chain

中文：

交易接入里的网络不是一句“低延迟”。我会拆成外部网络、Gateway read loop、内部队列/RPC、交易所或撮合侧响应、回报推送和冷路径。每个订单至少要能记录：client_send、gateway_recv、decode_done、risk_done、oms_accept、adapter_send、venue_ack/fill、report_push。指标上看 gateway decode P99、risk check P99、sequencer queue wait P99、adapter send P99、venue ack P99、report push P99、end-to-end P99/P999。

English:

Networking in trading access is not just saying low latency. I would split it into external network, gateway read loop, internal queue or RPC, venue or matching response, report push, and cold path. Each order should ideally record timestamps such as client_send, gateway_recv, decode_done, risk_done, oms_accept, adapter_send, venue_ack or fill, and report_push. Metrics include gateway decode P99, risk check P99, sequencer queue-wait P99, adapter send P99, venue ack P99, report push P99, and end-to-end P99/P999.

3.2.4 WebSocket 和行情/回报恢复 / WebSocket and market/order recovery

中文：

WebSocket 不能只当订阅接口。行情和订单回报要拆连接：public book、public low-frequency、private orders、private account/position。read loop 要薄，只做 read frame、timestamp、parse envelope、dispatch to bounded queue，不在 read loop 里构建 order book、写 DB、发 Kafka 或做复杂日志。断线后 public book 用 sequence gap + snapshot rebuild，private order 用 open orders、fills、positions、balance 做 reconcile。

English:

WebSocket should not be treated as just a subscription API. Market data and order reports should be separated into connections such as public book, public low-frequency data, private orders, and private account or position. The read loop should stay thin: read frame, timestamp, parse envelope, and dispatch to a bounded queue. It should not build the order book, write to the database, publish Kafka, or perform heavy logging. After disconnects, public books recover through sequence-gap detection and snapshot rebuild, while private orders recover through open orders, fills, positions, and balance reconciliation.

3.2.5 这块如何连接 NVIDIA JD / How this connects to the NVIDIA JD

中文：

这不是 GPU networking 的直接经验，但它和 NVIDIA JD 的系统能力高度相关。交易系统里的 Gateway/Risk/OMS/Adapter/Report 对应 AI inference 里的 gateway/scheduler/runtime/communication/output；订单状态机和 replay 对应 inference correctness 和 reproducibility；WebSocket/queue/backpressure/P99 对应 communication path 和 tail latency；分段 timestamp 和 latency histogram 对应 benchmark/profiling/debug checklist。

English:

This is not direct GPU networking experience, but it is highly relevant systems experience. Gateway/risk/OMS/adapter/report in trading systems maps conceptually to gateway/scheduler/runtime/communication/output in AI inference systems. Order state machines and replay map to inference correctness and reproducibility. WebSocket, queueing, backpressure, and P99 map to communication paths and tail latency. Stage timestamps and latency histograms map to benchmark, profiling, and debug checklists.

4. Polymarket Quant：预测市场交易系统

4.1 项目定位

Polymarket Quant 是一个 TypeScript monorepo，核心是预测市场中的交易系统。它包括：

market-data: 行情接入、订单簿、ticker
strategy: 分时低吸 YES/NO、对冲套利策略
execution: 订单执行、EIP-712 签名、Polymarket CLOB/CTF Exchange 交互
risk: 前置风控、仓位、滑点、日亏损、关联风险
accounting: PnL、FIFO/WAVG、资金审计
backtest: 历史回放、策略验证
cli: 统一启动入口

4.2 系统架构

flowchart TB
    WS["Polymarket WS REST"] --> MarketData["Market Data Service"]
    MarketData --> OrderBook["In Memory Order Book"]
    MarketData --> Strategy["Hedging Strategy"]
    OrderBook --> Strategy

    Strategy --> Signal["Trade Signal"]
    Signal --> Risk["Pre Trade Risk Manager"]
    Risk --> Executor["Execution Engine"]
    Executor --> Wallet["EIP712 Wallet Signer"]
    Wallet --> CLOB["Polymarket CLOB Exchange API"]
    CLOB --> OrderUpdate["Order Fill Update"]

    OrderUpdate --> Accounting["Accounting PnL FIFO WAVG"]
    OrderUpdate --> Strategy
    Accounting --> Audit["Audit Replay Reports"]
    Risk --> Metrics["Metrics Logs"]
    Executor --> Metrics

4.3 核心策略：YES/NO 成本锁定

预测市场二元事件中，YES + NO 理论到期价值为 1。策略逻辑是分别在不同时间点低吸 YES 和 NO，确保总成本低于阈值：

Cost(YES) + Cost(NO) < 0.99

这不是“预测涨跌”，而是利用 market microstructure 和散户情绪导致的错价。系统必须关心：

1. 两边建仓是否真的都成交。
2. order book 深度是否足够。
3. 加权平均成交价是否仍满足总成本约束。
4. 滑点是否吃掉理论利润。
5. 临近到期时如何 liquidation / hedge / unwind。

4.4 Data path

flowchart TB
    Tick["Order Book Ticker Update"] --> Normalize["Normalize Market Data"]
    Normalize --> StrategyCheck["Strategy Threshold Check"]
    StrategyCheck --> HedgeCheck["Yes No Cost Check"]
    HedgeCheck --> LiquidityCheck["Depth Slippage Check"]
    LiquidityCheck --> Signal["Signal"]
    Signal --> RiskGate["Risk Gate"]
    RiskGate --> BuildOrder["Build Polymarket Order"]
    BuildOrder --> SignOrder["EIP712 Sign"]
    SignOrder --> Submit["Submit Order"]
    Submit --> State["Order State Machine"]
    State --> Fill["Fill"]
    Fill --> Accounting["Position FIFO WAVG PnL"]

4.5 Control path

Control path 负责“系统能不能安全运行”：

配置校验 -> paper/live 模式隔离 -> API credentials 检查 -> balance 检查
-> risk config 加载 -> rate limiter / circuit breaker -> healthcheck
-> kill switch / graceful shutdown -> reconciliation

面试里你要强调：交易系统不能只有 data path；control path 决定系统出错时能不能停下来。

4.6 风控设计

Polymarket 项目里的风控模块做了几个关键检查：

英文回答：

The most important design principle was that risk checks had to be on the hot path before order submission. A strategy signal is only an intent; it must pass balance checks, position limits, open-order limits, daily-loss limits, liquidity checks, and cost-threshold checks before becoming an executable order.

4.7 Accounting：FIFO / WAVG / MTM

这个项目能体现 correctness-sensitive system。核心区别：

面试延展：

如果只在 fill 时更新 PnL，未实现盈亏会变旧。
如果 mark price 口径不统一，回测和实盘会对不上。
如果不记录 mark source，异常 PnL 无法复盘。

4.8 Polymarket 项目 90 秒英文讲法

One quant project I can talk about is a Polymarket prediction-market trading system built as a TypeScript monorepo. The system was not just a strategy script. It included market data ingestion, in-memory order book handling, a hedging strategy, an execution engine, EIP-712 order signing, pre-trade risk checks, accounting, and backtesting.

The core strategy was based on binary prediction markets, where YES and NO tokens settle to one dollar in total. The system tried to enter both sides at different times when the weighted total cost was below a threshold, for example less than 99 cents, while controlling depth, slippage, and position exposure.

From a systems perspective, the important part was the data path and safety path. A market data update produces an order book update, the strategy generates a signal, the signal goes through risk checks, the executor builds and signs an order, and fills are fed back into position and PnL accounting. The risk layer checked balance, position size, open orders, daily loss, liquidity depth, and cost thresholds before any order could be sent.

The relevance to NVIDIA is not the trading domain itself, but the systems method: event-driven architecture, hot-path latency, correctness-sensitive accounting, replay/backtest validation, observability, and failure containment.

5. Meme Quant：链上 smart-money / archive / backtest / MEV 系统

5.1 项目定位

Meme Quant 是多链链上交易系统，支持 Solana / Ethereum / Base / BSC。它的工程重点不是单一策略，而是一条完整策略验证和实盘安全流水线：

discover -> archive -> winners filtering -> backtest -> risk gate -> dry-run -> live

5.2 系统架构

flowchart TB
    Discovery["Wallet Discovery"] --> Candidate["Candidate Wallets"]
    Candidate --> Archive["Archive Node"]
    Archive --> SQLite["SQLite Archive DB"]
    SQLite --> Winners["Winners Filter"]
    Winners --> Backtest["Backtest Engine"]
    Backtest --> Decision["Go or No Go"]

    Decision --> Runtime["Trading Runtime"]
    Runtime --> Whale["Whale Tracker"]
    Whale --> Signal["Signal Generator"]
    Signal --> Risk["Risk Gate"]
    Risk --> Executor["Auto Trader"]
    Executor --> Portfolio["Portfolio PnL TCA"]

    Runtime --> Security["Kill Switch Trade Cap Tx Simulation"]
    Runtime --> Metrics["Prometheus Logs Dashboard"]

5.3 关键设计点

5.4 为什么 archive 很重要

如果只看实时信号，你不知道一个钱包是不是“聪明钱”。archive-node 把历史行为拉到本地，才能计算：

胜率
平均收益
持仓时间
最大亏损
是否只靠少数极端收益
不同市场周期是否稳定

这和 AI 系统里的 replay/evaluation 很像：没有历史回放，就无法证明策略或优化真的有效。

5.5 Meme Quant 90 秒英文讲法

Another quant project is a multi-chain smart-money and backtesting system. The key point is that I designed it as a validation pipeline rather than a blind trading bot. The flow is discovery, archive, winner filtering, backtesting, risk gating, dry-run, and only then live execution.

The archive-node subsystem continuously pulls historical swaps for tracked wallets into a local SQLite database. This allows the system to compute real historical win rate and behavior instead of assuming a wallet is smart. The backtest engine can then replay archive data, apply liquidity filters, risk controls, stop-loss logic, and walk-forward validation.

For live trading, the system has a risk gate, kill switch, trade cap guardian, transaction simulation guard, metrics, logs, and dashboard. So the focus is not just alpha generation. It is a production system with validation, safety, observability, and failure containment.

The transferable part for NVIDIA is that I approach complex systems through data path, validation path, risk controls, and measurable metrics. This is similar to how I would approach inference-system or GPU-networking prototypes.

6. CeFi C++ Low-Latency Infra：行情网关、订单路由、前置风控

6.1 项目定位

这是最接近 NVIDIA JD 中 C++ / system programming / performance profiling / architecture 的 quant 项目。它是 C++20 monorepo，包含：

market_data_gateway: 行情采集与标准化，预留 DPDK
order_router: 订单类型、订单状态机、批量状态迁移 benchmark
pretrade_risk: hot-path 前置风控检查、吞吐 benchmark
shared perf: benchmark 输出格式、latency stats
perf_gate.py: 性能门禁

6.2 系统图

flowchart TB
    Exchange["Exchange Feed"] --> Rx["RX Backend"]
    Rx --> Kernel["Kernel Socket Backend"]
    Rx --> DPDK["DPDK Backend Stub Future"]
    Kernel --> Normalize["Market Data Gateway"]
    DPDK --> Normalize
    Normalize --> Ring["SPSC Ring Buffer"]
    Ring --> Strategy["Strategy Signal"]
    Strategy --> PreRisk["Pre Trade Risk"]
    PreRisk --> Router["Order Router"]
    Router --> State["Order State Machine"]
    State --> ExchangeAPI["Exchange API"]

    Ring --> Bench["Benchmark"]
    PreRisk --> Bench
    Router --> Bench
    Bench --> Gate["Perf Gate"]

6.3 关键工程点

6.4 和 UCX/NVIDIA networking 怎么类比

不要说自己写过 UCX。正确类比是：

C++ CeFi 项目里，RX backend 抽象让 kernel socket 和 DPDK 后端可以切换；
UCX 里，transport abstraction 让 TCP/RDMA/shared memory/CUDA-aware path 可以选择。

二者不是同一个技术，但架构思想相似：
统一上层语义，隐藏下层 transport 差异，同时保留性能可观测性和 fallback。

英文回答：

In the C++ CeFi infrastructure project, I used a backend abstraction for market-data receiving paths, where the system could run on a kernel-socket backend and later evolve toward a DPDK backend. I would not claim this is UCX experience, but the architectural idea is similar: keep the upper-layer semantics stable while allowing different low-level transports, and validate each backend with benchmarks and latency metrics.

6.5 C++ 项目 90 秒英文讲法

The C++ CeFi infrastructure project was a low-latency trading-system skeleton. It included a market data gateway, an order router, and a pre-trade risk engine. The market data gateway had a unified RX backend abstraction, with a kernel-socket path and a DPDK-ready path. The data path used an SPSC ring buffer for producer-consumer handoff.

The order router focused on order types and order-state transitions, and the pre-trade risk engine performed synchronous hot-path checks before orders could be routed. I also added benchmark binaries and a performance gate script that parses throughput and P99 latency and fails if thresholds are not met.

The relevance to this NVIDIA role is system programming, data-path design, backend abstraction, latency metrics, and performance regression control. It is not GPU networking, but it shows that I think in terms of hot paths, transport boundaries, and measurable performance.

7. Cross-exchange arbitrage / market making design

7.1 Arbx Quant

Arbx Quant 是跨交易所套利系统入口，模块包括：

config: API/DB/env config
data processor: 多交易所行情数据处理
arbitrage strategy: 机会识别
trade executor: 执行
event emitter: 高频事件总线
logger: structured logging
main loop: fetch market data -> analyze opportunity -> handle opportunity

系统图：

flowchart TB
    Config["Config Env"] --> Runtime["Runtime Context"]
    Runtime --> Collector["Market Data Collector"]
    Collector --> Processor["Data Processor"]
    Processor --> Analyzer["Opportunity Analyzer"]
    Analyzer --> Strategy["Arbitrage Strategy"]
    Strategy --> Executor["Trade Executor"]
    Executor --> Events["Event Bus"]
    Events --> Logger["Logger Metrics"]
    Events --> Risk["Risk Alerts"]

7.2 CEX Unreal LP / Market Making

这个设计文档是黄金永续做市系统，核心是三档模式：

做市系统架构：

flowchart TB
    Feed["Bitget OKX Binance Feed"] --> FairPrice["Fair Price Engine"]
    FairPrice --> Signal["Signal Engine"]
    Signal --> Mode["Mode Selector"]
    Mode --> Passive["Passive Quoting"]
    Mode --> Defensive["Defensive Hedge"]
    Mode --> Aggressive["Aggressive Quoting"]

    Passive --> OMS["OMS"]
    Defensive --> OMS
    Aggressive --> OMS
    OMS --> Risk["Risk Manager"]
    Risk --> Router["Order Router"]
    Router --> Exchange["Exchange Adapters"]
    Exchange --> Fill["Fill"]
    Fill --> Position["Position PnL"]
    Position --> Hedge["Hedge Engine"]

7.3 面试连接

这个项目能讲：

1. mode switching 和 runtime scheduling。
2. hot path：tick -> signal -> quote -> risk -> order。
3. risk-first design：DD、inventory、hedge latency、API rate limit。
4. system architecture：strategy layer、core service layer、connectivity layer、infra layer。
5. C++ low latency：event bus、SPSC/MPSC queue、market data、order router。

8. 面试官可能怎么深挖 quant 项目

Q1: Why is this relevant to an AI networking role?

中文回答：

我不会把 quant 项目说成直接的 AI networking production experience。它的相关性在系统能力上：事件驱动 data path、低延迟 hot path、前置风控、状态机、benchmark、P99、可观测性和 replay/backtest。这些能力迁移到 AI infrastructure，就是 request path、communication path、runtime scheduling、benchmark/profiling 和 failure containment。

English answer:

I would not present the quant projects as direct AI networking experience. The relevance is the systems capability: event-driven data paths, latency-sensitive hot paths, pre-trade risk gates, state machines, benchmarks, P99 thinking, observability, and replay or backtest validation. In AI infrastructure, the analogous problems are request paths, communication paths, runtime scheduling, profiling, benchmarking, and failure containment.

Q2: What was the hardest system problem?

推荐回答：

The hardest part was not writing a single strategy rule. It was making the system safe and diagnosable. A trading signal can be wrong, market data can be stale, an API can fail, and execution can slip. So the architecture had to separate signal generation from risk validation and execution. Every order needed a traceable path from market data to signal to risk gate to execution to fill to accounting.

Q3: How did you think about latency?

推荐回答：

I split latency into stages: market data ingestion, normalization, strategy evaluation, risk checks, order construction, signing, submission, exchange acknowledgment, and fill feedback. Then I would measure the critical path and distinguish average latency from P99. For the C++ low-latency project, I also added benchmark outputs and a performance gate so that regressions could be caught automatically.

Q4: What can go wrong in a live trading system?

回答方向：

stale market data
wrong mark price
API timeout
partial fill
duplicate order
nonce/signature issue
slippage larger than expected
position drift
PnL mismatch
retry storm
kill switch failure
configuration error

英文收束：

That is why I separate data path, control path, and safety path. A strategy signal is not executable until it passes validation, and every execution result must flow back into state, risk, and accounting.

Q5: What would you improve?

推荐回答：

I would improve three areas. First, stronger schema validation at API boundaries, because exchange responses should not be trusted. Second, better MTM and reconciliation, so PnL and position state do not become stale. Third, more systematic latency tracing across market data, strategy, risk, execution, and accounting, so performance claims are backed by evidence.

Q6: 交易接入 Gateway 怎么设计 / How would you design a trading gateway?

中文回答：

Gateway 要薄，负责连接、协议、session、认证、限频、clOrdId 幂等入口和回报推送，不应该塞满交易所细节。订单状态机、撮合/外部交易所适配、对账应该放到 OMS 和 Adapter。热路径上 Gateway 不查 DB、不等 Kafka、不远程读配置、不同步写大日志。这样才能保证低延迟和故障隔离。

English answer:

The gateway should stay thin. It should handle connections, protocol decoding, sessions, authentication, rate limiting, client-order-id deduplication entry points, and report push. It should not contain all venue-specific details. Order state machines, matching or external venue adaptation, and reconciliation should belong to the OMS and adapters. On the hot path, the gateway should not query databases, wait for Kafka, fetch remote configuration, or synchronously write heavy logs. That keeps latency low and failure domains isolated.

Q7: WebSocket 行情和订单回报怎么处理 / How would you handle WebSocket market data and order reports?

中文回答：

我会把连接拆开：public book、public low-frequency ticker/funding/mark price、private order reports、private account/position。read loop 只做 read frame、timestamp、parse envelope、dispatch to bounded queue。不要在 read loop 里构建 order book、写 DB、发 Kafka 或做复杂日志。行情断线用 sequence gap + snapshot rebuild；订单回报断线后查 open orders、fills、positions、balance 做 reconcile。

English answer:

I would separate the connections: public book, public low-frequency ticker/funding/mark price, private order reports, and private account or position updates. The read loop should only read frames, timestamp them, parse envelopes, and dispatch to bounded queues. It should not build the order book, write databases, publish Kafka, or perform heavy logging. Market data disconnects should recover through sequence-gap detection and snapshot rebuild. Private order disconnects should recover through open orders, fills, positions, and balance reconciliation.

Q8: 撮合/OMS 状态机有哪些关键不变量 / What are the key invariants in matching or OMS state machines?

中文回答：

关键不变量是：同一 clOrdId 不能创建两笔订单；filled_qty 只能单调增加；leaves_qty 不能小于 0；终态不能回退；同一 fill_id 不能重复入账；timeout 不能直接当失败，要进入 unknown/reconcile；撤单只能撤 leaves_qty，不能撤已经成交的部分。所有状态变化都要 journal，reconcile 也要通过 compensation event 进入同一套状态机，不能直接改 DB。

English answer:

The key invariants are: the same client order id cannot create two independent orders; filled quantity only increases; leaves quantity cannot be negative; terminal states cannot roll back; the same fill id cannot be booked twice; timeout should not be treated as failure directly but should enter unknown or reconcile; and cancel can only apply to leaves quantity, not already filled quantity. Every state transition should be journaled. Reconciliation should generate compensation events and go through the same state machine, instead of directly modifying the database.

Q9: 网络慢或 P99 高怎么定位 / How would you debug network slowness or high P99?

中文回答：

我会先拆分段延迟，而不是直接说网络慢。时间戳至少包括 client_send、gateway_recv、decode_done、risk_done、oms_accept、adapter_send、venue_ack/fill、report_push。然后看 P50/P95/P99/P999、queue depth、reconnect、TCP retransmit、slow consumer、Kafka lag、DB/reconcile 是否误入热路径。如果 gateway 到 risk 稳定，但 adapter_send 到 venue_ack 抖，问题可能在外部 venue 或网络；如果 risk_done 到 oms_accept 抖，可能是 sequencer、queue、lock 或 shard 热点。

English answer:

I would first break latency into stages instead of simply saying the network is slow. Timestamps should include client_send, gateway_recv, decode_done, risk_done, oms_accept, adapter_send, venue_ack or fill, and report_push. Then I would check P50/P95/P99/P999, queue depth, reconnects, TCP retransmits, slow consumers, Kafka lag, and whether database or reconciliation work accidentally entered the hot path. If gateway-to-risk is stable but adapter_send-to-venue_ack is unstable, the problem may be the external venue or network. If risk_done-to-oms_accept is unstable, it may be the sequencer, queue, lock contention, or shard hotspot.

9. 你应该怎么把 quant 放进自我介绍

不要一上来讲 trading 收益。应该这样带：

Besides AI/LLM engineering work, I also built several quant trading-system prototypes. The reason I mention them is not the trading domain itself, but the systems work behind them: event-driven architecture, market data pipelines, low-latency order routing, pre-trade risk gates, backtesting/replay, PnL accounting, and observability. These projects strengthened my ability to reason about hot paths, correctness, and production safety.

如果对方继续追，再展开 Polymarket 或 C++ CeFi。

10. 30 秒、60 秒、2 分钟版本

30 秒版本

I have also built quant trading-system prototypes, including a Polymarket prediction-market trading system, a smart-money backtesting pipeline, and a C++ low-latency CeFi infrastructure skeleton. I use these projects to demonstrate systems skills: event-driven data paths, hot-path latency, risk gates, state machines, replay/backtest validation, and performance benchmarking.

60 秒版本

One project family I can discuss is quant trading infrastructure. The Polymarket system was a TypeScript monorepo with market data, strategy, execution, EIP-712 signing, pre-trade risk, accounting, and backtesting. The meme-quant project focused on a validation pipeline: wallet discovery, archive-node, winner filtering, backtesting, risk gate, and live runtime safety. I also built a C++ CeFi skeleton with a market data gateway, SPSC ring buffer, order router, pre-trade risk engine, and performance gate.

The common theme is not trading profit. It is systems engineering: clean data paths, latency-sensitive hot paths, risk controls, state correctness, replayability, observability, and benchmarks. Those are directly relevant to how I would approach AI infrastructure and GPU networking prototypes.

2 分钟版本

The quant projects are useful examples of how I design performance-sensitive systems. In the Polymarket project, the system was structured as a TypeScript monorepo with separate packages for market data, strategy, execution, risk, accounting, backtest, and CLI. The execution path starts from market data and order book updates, then the strategy generates a signal, the risk layer validates it, the execution engine builds and signs an EIP-712 order, and fills are fed back into accounting and strategy state.

In the meme-quant project, the focus was more on validation and production safety. It used a pipeline of discovery, archive, winner filtering, backtest, risk gate, dry-run, and live execution. It also included kill switch, trade caps, transaction simulation guards, metrics, and logs.

The C++ CeFi project was closer to low-latency infrastructure. It had a market data gateway with kernel and DPDK-ready receive backends, an SPSC ring buffer, an order router, a pre-trade risk engine, and benchmark gates for throughput and P99 latency.

I would not claim these are direct UCX or NIXL systems. The transferable part is the engineering method: separate data path and control path, define measurable metrics, protect the hot path with risk checks, and validate performance with benchmarks and profiling.

11. 面试风险和边界

12. 最后复习清单

1. Polymarket: market data -> strategy -> risk -> execution -> accounting。
2. Meme Quant: discover -> archive -> winners -> backtest -> risk -> live。
3. C++ CeFi: RX backend -> SPSC ring -> strategy -> pre-risk -> router。
4. 每个项目都要讲清：data path、control path、risk path、metrics。
5. 不夸大：quant 是系统能力证明，不是 NIXL/GPUNetIO production experience。