Day 119
Day 119：系统设计限时练习 — 跨链聚合器 + 清算监控
两道系统设计限时练习：①45分钟设计跨链DEX聚合器 ②45分钟设计实时清算监控系统，含完整架构图、组件设计、trade-off分析
2026-05-06
交易系统设计面试跨链聚合器清算监控限时练习Day119
核心概念
系统设计面试的重要性
一句话定义：系统设计面试考察的是将模糊需求转化为可实施的技术方案的能力，包括需求分析、架构选型、组件设计、Trade-off 分析和失败场景处理。
类比理解：系统设计面试就像考建筑师——不是让你砌砖（写代码），而是让你设计大楼的整体结构、选择建材、规划管道电路、评估抗震能力。45 分钟内完成从蓝图到验证的全过程。
系统设计面试评分维度
| 维度 | 权重 | 考察内容 |
|---|---|---|
| 需求分析 | 15% | 能否从模糊需求中提出关键问题 |
| 规模估算 | 10% | 能否做合理的量化估算 |
| 高层架构 | 25% | 整体方案是否合理、可扩展 |
| 核心组件 | 25% | 关键模块的详细设计 |
| Trade-off | 15% | 对方案的取舍分析是否深入 |
| 扩展与容错 | 10% | 失败场景和扩展方案 |
练习一：跨链 DEX 聚合器（45 分钟）
Step 1：需求分析（5 分钟）
面试官问题：设计一个跨链 DEX 聚合器
关键问题（向面试官确认）：
├── Q1：支持多少条链？
│ └── 假设：10+ 条链（Ethereum、Arbitrum、Optimism、
│ Base、Polygon、BSC、Avalanche、Solana 等）
├── Q2：支持多少个底层 DEX？
│ └── 假设：每条链 2-5 个，总计 20+ 个 DEX
├── Q3：是否支持跨链 Swap？
│ └── 是（用户输入 Chain A Token X → 输出 Chain B Token Y）
├── Q4：性能要求？
│ └── 报价 < 3 秒，执行确认 < 跨链桥时间 + 30 秒
└── Q5：用户规模？
└── DAU 50K，峰值 QPS ~50
功能需求（FR）：
├── FR1：单链聚合（同链多 DEX 最优路由）
├── FR2：跨链聚合（跨链桥 + DEX 组合最优路径）
├── FR3：报价对比（展示多条路径及预估费用）
├── FR4：交易执行与状态追踪
└── FR5：MEV 保护（可选）
非功能需求（NFR）：
├── NFR1：报价延迟 < 3 秒
├── NFR2：价格准确度 > 99%（实际执行 vs 报价）
├── NFR3：可用性 > 99.9%
├── NFR4：支持 10+ 链和 20+ DEX
└── NFR5：可扩展（新增链/DEX 应在 1 天内完成）
Step 2：规模估算（3 分钟）
规模估算：
═══════════════════════════════════════
用户量：
├── DAU：50,000
├── 人均请求报价：10 次/天
├── 人均执行交易：1-2 次/天
├── 总报价请求：500,000 / 天
├── 总交易执行：75,000 / 天
└── 峰值 QPS：~50（报价），~5（执行）
数据量：
├── 价格数据：10 链 × 1000 交易对 × 每 500ms 更新
│ = 20,000 次更新/秒
├── 交易记录：75,000 / 天 × 5KB = 375 MB/天
├── 历史报价：500,000 / 天 × 2KB = 1 GB/天
└── 总存储增长：~1.5 GB/天 ≈ 45 GB/月
基础设施需求（粗略）：
├── 计算：中等（CPU 密集在路由算法）
├── 内存：高（价格缓存需要大量 RAM）
├── 网络：中等（与多链 RPC 通信）
└── 存储：中低（大部分是缓存数据）
Step 3：高层架构（10 分钟）
跨链 DEX 聚合器高层架构：
═══════════════════════════════════════
┌─────────────────────────────────────────────┐
│ 用户前端 │
│ (React/Next.js, WalletConnect) │
└──────────────────┬──────────────────────────┘
│ HTTPS / WebSocket
▼
┌─────────────────────────────────────────────┐
│ API Gateway │
│ (Rate Limit / Auth / Load Balance) │
└──────┬───────┬────────┬──────────┬──────────┘
│ │ │ │
▼ ▼ ▼ ▼
┌──────────┐ ┌────────┐ ┌────────┐ ┌──────────┐
│ 报价服务 │ │路由引擎│ │执行服务│ │ 状态追踪 │
│ (Quote) │ │(Route) │ │(Exec) │ │(Tracker) │
└────┬─────┘ └───┬────┘ └───┬────┘ └────┬─────┘
│ │ │ │
▼ ▼ ▼ ▼
┌─────────────────────────────────────────────┐
│ 价格数据层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 价格缓存 │ │ 流动性池 │ │ Gas 预估 │ │
│ │ (Redis) │ │ (Redis) │ │ (Redis) │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└──────────────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ 链上数据采集层 │
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │
│ │ETH │ │ARB │ │OP │ │BASE│ │SOL │ ... │
│ └────┘ └────┘ └────┘ └────┘ └────┘ │
│ (RPC Nodes / WebSocket Subscriptions) │
└─────────────────────────────────────────────┘
跨链执行路径：
用户请求：ETH(Ethereum) → USDC(Arbitrum)
路径 1：ETH→WETH→USDC(Eth)→Bridge→USDC(Arb)
路径 2：ETH→Bridge→ETH(Arb)→USDC(Arb)
路径 3：ETH→WETH→Bridge(Stargate)→USDC(Arb)
路由引擎比较所有路径的：
├── 最终获得的 USDC 数量
├── Gas 费用（包含桥费用）
├── 预计完成时间
├── 滑点风险
└── 推荐最优路径
Step 4：核心组件设计（15 分钟）
组件 1：价格缓存系统
价格缓存设计：
═══════════════════════════════════════
数据结构（Redis）：
├── Key: price:{chain}:{dex}:{tokenA}:{tokenB}
├── Value: { price, liquidity, timestamp, block }
├── TTL: 500ms（高频更新）
└── 更新频率：每 500ms 从链上拉取
更新策略：
├── 主动推送：WebSocket 订阅链上事件
│ └── 监听 Swap/Sync 事件实时更新
├── 定期拉取：每 500ms 查询 RPC
│ └── 作为推送的备份和校验
└── 惰性更新：用户请求时检查时效
└── 如缓存 > 1s 则触发即时更新
缓存层次：
L1: 本地内存（进程内，<1ms，存最热门交易对）
L2: Redis 集群（<5ms，存所有活跃交易对）
L3: 链上查询（<500ms，缓存未命中时回源）
组件 2：路由算法引擎
路由算法设计：
═══════════════════════════════════════
问题建模：
├── 将所有链、DEX、Token 建模为有向加权图
├── 节点 = Token（带链标识）
├── 边 = 交易路径（DEX swap 或 Bridge）
├── 权重 = 预期滑点 + Gas + 桥费 + 时间成本
└── 目标：找到权重最小的路径
图示例：
┌──────────┐
Uniswap │ETH(Eth) │ Stargate
┌──────────▶│ WETH │──────────┐
│ └──────────┘ │
┌───────┴──┐ ┌────▼─────┐
│ETH(Eth) │ Arbitrum Bridge │USDC(Arb) │
│ │──────────────────────▶ │ │
└───────┬──┘ └────▲─────┘
│ ┌──────────┐ │
└──────────▶│USDC(Eth) │──────────┘
Uniswap │ │ Hop Bridge
└──────────┘
算法：改进的 Dijkstra
核心改进点：
├── 1. 滑点感知：大额订单需要考虑流动性深度
│ └── 拆分到多条路径（Split Routing）
├── 2. Gas 感知：不同链 Gas 成本差异巨大
│ └── Ethereum: $5-20 vs Arbitrum: $0.01-0.10
├── 3. 时间感知：桥的延迟从 1 分钟到 30 分钟
│ └── 用户可选"最快"或"最便宜"
└── 4. 并发评估：同时计算 Top-K 条路径
拆单策略（Split Routing）：
├── 大额订单可能在单个 DEX 滑点过大
├── 将订单拆分到多个 DEX/路径
├── 优化目标：最小化总滑点 + Gas
├── 示例：$100K USDC→ETH
│ ├── 60% → Uniswap V3（流动性最深）
│ ├── 30% → Curve（稳定币路径好）
│ └── 10% → SushiSwap（补充流动性）
└── 算法：凸优化 / 贪心分配
组件 3：Solver 竞拍系统
Solver 荷兰拍卖设计（Intent-Based）：
═══════════════════════════════════════
流程：
1. 用户提交 Intent："我要用 1 ETH 换尽量多的 USDC"
2. 系统广播 Intent 到 Solver 网络
3. Solver 竞价（荷兰拍卖 / 密封报价）
4. 最优 Solver 执行交易
5. 用户获得最优价格
荷兰拍卖时间线：
价格
│
│ ████
│ ████████
│ ████████████
│ ████████████████ ← 起始报价（最优价）
│ ████████████████████
│ ████████████████████
│ ████████████████████ ← 当前价
│ ████████████████████
│ ███████████████████
│ ████████████████ ← 成交价
└───────────────────────────────────────── 时间
0s 3s 5s
Solver 激励：
├── 执行奖励：用户支付的服务费（0.01-0.05%）
├── MEV 捕获：Solver 可内化 MEV
├── 声誉积分：执行率高的 Solver 优先接单
└── Slash 机制：未执行的 Solver 扣押保证金
优于传统路由的地方：
├── Solver 有私有流动性（做市库存）
├── 可以批量匹配（Order-Flow Auction）
├── MEV 被 Solver 捕获并部分返还用户
└── 用户体验更简单（只需声明意图）
组件 4：交易状态机
跨链交易状态机：
═══════════════════════════════════════
┌──────────┐
│ CREATED │
└────┬─────┘
│ 用户签名
┌────▼─────┐
│ SIGNED │
└────┬─────┘
│ 提交到源链
┌────▼─────┐
┌─────── │ PENDING │ ──────┐
│ └────┬─────┘ │
│ 超时 │ 源链确认 │ 失败
│ ┌────▼─────┐ │
│ │ SRC_DONE │ │
│ └────┬─────┘ │
│ │ 桥开始 │
│ ┌────▼─────┐ │
│ │ BRIDGING │───────┤
│ └────┬─────┘ │
│ │ 桥完成 │
│ ┌────▼─────┐ │
│ │ DST_SWAP │───────┤
│ └────┬─────┘ │
│ │ 目标链完成 │
│ ┌────▼─────┐ ┌────▼─────┐
│ │ COMPLETED│ │ FAILED │
│ └──────────┘ └────┬─────┘
│ │
└───────────────────────────┘
需要退款/重试
关键设计：
├── 每个状态转换都有超时机制
├── FAILED 状态需要自动/手动退款
├── 所有状态变更记录审计日志
├── 前端轮询/WebSocket 推送状态
└── 桥延迟期间显示预估时间
Step 5：Trade-off 分析（7 分钟）
关键 Trade-off：
═══════════════════════════════════════
Trade-off 1：自建路由 vs Solver 网络
┌──────────────┬────────────────┬────────────────┐
│ │ 自建路由引擎 │ Solver 网络 │
├──────────────┼────────────────┼────────────────┤
│ 延迟 │ 快（<1s） │ 稍慢（2-5s） │
│ 价格优化 │ 有限（公开池） │ 更优（私有流动性）│
│ MEV 保护 │ 需额外方案 │ 内置 │
│ 开发复杂度 │ 高 │ 中 │
│ 可扩展性 │ 每加链需开发 │ Solver 自动扩展 │
│ 可靠性 │ 自控 │ 依赖 Solver │
└──────────────┴────────────────┴────────────────┘
推荐：混合方案——简单路由自建，复杂跨链用 Solver
Trade-off 2：价格精度 vs 响应速度
├── 高精度：查询所有 DEX 实时价格 → 慢（3-5s）
├── 高速度：使用缓存价格 → 可能有偏差
└── 推荐：先返回缓存报价，后台刷新后更新
Trade-off 3：去中心化 vs 用户体验
├── 完全链上：透明但慢、贵
├── 链下撮合+链上结算：快但有信任假设
└── 推荐：链下报价和路由，链上执行和结算
失败场景处理：
├── 桥故障：自动选择备用桥或退款
├── 价格偏差 >1%：警告用户重新报价
├── Solver 不执行：保证金扣押 + 自动路由执行
├── 链拥堵：动态调整 Gas + 提示用户等待
└── 部分执行：确保原子性或自动退款
MEV 保护方案：
├── 1. Private Mempool（Flashbots Protect）
├── 2. Solver 内化 MEV 后返还
├── 3. 限价单（用户设置最低接受价格）
├── 4. 批量拍卖（CoW Protocol 方式）
└── 推荐：默认使用 Private Mempool + 限价保护
Step 6：面试总结陈述（5 分钟）
总结框架：
1. 核心设计选择
├── 混合架构：简单路由自建 + 跨链用 Solver
├── 多层缓存：L1 内存 + L2 Redis + L3 链上
├── Intent-Based：用户只需声明意图
└── 状态机：跨链交易全生命周期管理
2. 扩展方向
├── 新增链：插件化适配器，1 天内接入
├── 新增 DEX：配置化接入，无需改代码
├── 性能扩展：报价服务水平扩展
└── AI 增强：用历史数据预测最优路由
3. 监控指标
├── 报价响应时间 P99 < 3s
├── 报价 vs 实际执行偏差 < 0.5%
├── 跨链交易成功率 > 99%
└── 用户满意度（执行价格排名）
练习二：实时清算监控系统（45 分钟）
Step 1：需求分析（5 分钟）
面试官问题：设计一个实时清算监控系统
关键问题确认：
├── Q1：监控哪些协议？
│ └── 5+ Perp DEX（Hyperliquid、dYdX、GMX、Drift、Vertex）
├── Q2：监控哪些指标？
│ └── 清算事件、清算金额、清算模式、大额清算告警
├── Q3：延迟要求？
│ └── 清算事件发生后 < 5 秒内展示
├── Q4：用户是谁？
│ └── 交易者、风控团队、研究分析师
└── Q5：告警需求？
└── 大额清算、连锁清算、异常清算模式
功能需求：
├── FR1：实时采集 5+ Perp DEX 的清算事件
├── FR2：清算事件可视化 Dashboard
├── FR3：清算模式分类与统计
├── FR4：多级告警系统
├── FR5：历史清算数据查询与导出
└── FR6：预测性清算预警（扩展）
非功能需求：
├── NFR1：端到端延迟 < 5 秒
├── NFR2：数据不丢失（At-least-once）
├── NFR3：支持每秒 1000+ 清算事件（极端行情）
├── NFR4：历史数据保留 ≥ 1 年
└── NFR5：Dashboard 刷新频率 ≥ 1 秒
Step 2：规模估算（3 分钟）
规模估算：
═══════════════════════════════════════
清算事件量：
├── 正常日：5,000 - 10,000 事件/天
├── 波动日：10,000 - 50,000 事件/天
├── 极端日（如 2025.10 闪崩）：100,000+ 事件/天
├── 平均 QPS：~1-5（正常），50-100（波动），500+（极端）
└── 设计峰值：1,000 QPS
单个清算事件数据：
├── 大小：~1 KB（含元数据）
├── 日存储：正常 10 MB，极端 100 MB
├── 年存储：~10 GB（压缩后 ~3 GB）
└── 存储成本很低
Dashboard 并发：
├── DAU：5,000（交易者+分析师）
├── 同时在线：~500
├── WebSocket 连接：500（推送更新）
└── 历史查询 QPS：~10
Step 3：高层架构（10 分钟）
实时清算监控系统高层架构：
═══════════════════════════════════════
数据采集层 消息队列 流处理层
┌──────────┐ ┌─────────┐ ┌──────────┐
│Hyperliquid│──────────▶│ │ │ │
│ Indexer │ │ │ │ 清算分类 │
├──────────┤ │ │───▶│ 模式检测 │
│ dYdX │──────────▶│ Kafka │ │ 聚合统计 │
│ Indexer │ │ │ │ 告警触发 │
├──────────┤ │ │ │ │
│ GMX │──────────▶│ │ └────┬─────┘
│ Indexer │ │ │ │
├──────────┤ │ │ ┌────▼─────┐
│ Drift │──────────▶│ │ │ 存储层 │
│ Indexer │ │ │ ├──────────┤
├──────────┤ │ │ │TimescaleDB│
│ Vertex │──────────▶│ │ │(时序数据) │
│ Indexer │ └─────────┘ │ │
└──────────┘ │Redis │
│(实时缓存)│
│ │
│ClickHouse│
│(分析查询)│
└────┬─────┘
│
┌────▼─────┐
│ API 层 │
│ REST + │
│ WebSocket │
└────┬─────┘
│
┌────▼─────┐
│Dashboard │
│(React + │
│ D3.js) │
└──────────┘
数据流：
链上事件 → Indexer(自建) → Kafka → Stream Processor
→ TimescaleDB(持久化) + Redis(实时) → API → Dashboard
Step 4：核心组件设计（15 分钟）
组件 1：自建索引器
自建索引器设计：
═══════════════════════════════════════
为什么自建而非用第三方？
├── 延迟要求：第三方 API 通常 10-30s 延迟
├── 可靠性：不依赖第三方服务可用性
├── 定制化：可以精确提取需要的数据
└── 成本：高频查询第三方 API 费用高
每个协议的索引策略：
Hyperliquid（自有 L1）：
├── WebSocket 订阅清算事件
├── 监听 Liquidation 类型的交易
├── 解析 clearinghouseState 数据
└── 延迟：< 1 秒
dYdX V4（Cosmos App-chain）：
├── 订阅 Tendermint WebSocket
├── 过滤 Liquidation 类型的 Tx
├── 解析 SubaccountUpdate 事件
└── 延迟：< 2 秒
GMX V2（Arbitrum）：
├── 订阅 Arbitrum 节点事件
├── 监听 PositionDecrease + LiquidationEvent
├── 解析事件日志
└── 延迟：< 3 秒
统一数据模型：
┌─────────────────────────────────────┐
│ LiquidationEvent { │
│ id: string (UUID) │
│ protocol: enum (HL/DYDX/GMX/...) │
│ chain: string │
│ timestamp: datetime │
│ block_number: uint64 │
│ tx_hash: string │
│ trader: address │
│ market: string (BTC-USD/ETH-USD) │
│ side: enum (LONG/SHORT) │
│ size_usd: decimal │
│ collateral_usd: decimal │
│ liquidation_price: decimal │
│ mark_price: decimal │
│ penalty_usd: decimal │
│ liquidator: address (if any) │
│ type: enum (详见清算分类) │
│ } │
└─────────────────────────────────────┘
组件 2：清算模式分类
清算事件四大分类：
═══════════════════════════════════════
类型 1：常规清算（Normal Liquidation）
├── 触发：保证金率 < 维持保证金率
├── 特征：单个仓位独立清算
├── 占比：~70% 的清算事件
└── 风险：低（系统正常运作）
类型 2：连锁清算（Cascade Liquidation）
├── 触发：大额清算 → 价格冲击 → 更多清算
├── 特征：短时间内（<5分钟）同方向大量清算
├── 识别规则：
│ └── 5 分钟内同市场同方向清算 > 20 笔
│ 且总金额 > $10M
├── 占比：~15%
└── 风险：高（可能引发市场崩溃）
类型 3：猎杀清算（Hunting Liquidation）
├── 触发：价格被有意推向清算密集区
├── 特征：价格触及清算区后快速反弹
├── 识别规则：
│ └── 价格在 10 分钟内先跌 >3% 再涨 >2%
│ 且清算集中在底部 1% 价格区间
├── 占比：~10%
└── 风险：中高（市场操纵行为）
类型 4：ADL 清算（Auto-Deleveraging）
├── 触发：保险基金耗尽时强制减仓盈利方
├── 特征：非自愿的仓位缩减
├── 识别规则：ADL 标记或保险基金余额骤降
├── 占比：~5%
└── 风险：极高（系统风险信号）
组件 3：告警规则引擎
三层告警规则：
═══════════════════════════════════════
Layer 1：简单规则（实时触发）
├── 大额清算：单笔 > $1M → P1 告警
├── 超大额清算：单笔 > $10M → P0 告警
├── 高频清算：同市场 1 分钟内 > 50 笔 → P1
└── ADL 触发：任何 ADL 事件 → P0
Layer 2：模式规则（滑动窗口）
├── 连锁清算：5 分钟窗口内同方向 > $10M → P0
├── 多市场联动：3+ 市场同时高频清算 → P0
├── 保险基金下降：30 分钟内下降 > 10% → P1
└── 清算猎杀模式：价格 V 型反转 + 集中清算 → P1
Layer 3：统计规则（历史对比）
├── 清算量异常：当前小时 > 30 天均值 5x → P1
├── 清算方向偏斜：多空比 > 9:1 → P1
└── 新市场异常：上线 <7 天的市场清算率 > 5% → P1
告警通知渠道：
├── P0（紧急）：Telegram + PagerDuty + 短信
├── P1（重要）：Telegram + Email
├── P2（关注）：Dashboard 标注 + 日报
└── 所有告警写入日志和 Dashboard
组件 4：数据存储 — TimescaleDB 表设计
TimescaleDB 表设计（适合时序数据）：
-- 清算事件表（Hypertable，按时间分区）
CREATE TABLE liquidation_events (
id UUID PRIMARY KEY,
protocol TEXT NOT NULL,
chain TEXT NOT NULL,
timestamp TIMESTAMPTZ NOT NULL,
block_number BIGINT,
tx_hash TEXT,
trader TEXT,
market TEXT NOT NULL,
side TEXT NOT NULL, -- LONG / SHORT
size_usd DECIMAL(20,2),
collateral DECIMAL(20,2),
liq_price DECIMAL(20,8),
mark_price DECIMAL(20,8),
penalty_usd DECIMAL(20,2),
liq_type TEXT, -- NORMAL/CASCADE/HUNTING/ADL
metadata JSONB
);
SELECT create_hypertable('liquidation_events', 'timestamp');
-- 常用查询示例
-- 1. 过去 24 小时各协议清算总额
SELECT protocol,
COUNT(*) as liq_count,
SUM(size_usd) as total_size,
AVG(size_usd) as avg_size,
MAX(size_usd) as max_size
FROM liquidation_events
WHERE timestamp > NOW() - INTERVAL '24 hours'
GROUP BY protocol
ORDER BY total_size DESC;
-- 2. 连锁清算检测（5分钟窗口）
SELECT time_bucket('5 minutes', timestamp) as bucket,
market,
side,
COUNT(*) as liq_count,
SUM(size_usd) as total_size
FROM liquidation_events
WHERE timestamp > NOW() - INTERVAL '1 hour'
GROUP BY bucket, market, side
HAVING SUM(size_usd) > 10000000 -- > $10M
ORDER BY bucket DESC;
-- 3. 每小时清算热力图数据
SELECT time_bucket('1 hour', timestamp) as hour,
market,
SUM(CASE WHEN side='LONG' THEN size_usd ELSE 0 END) as long_liq,
SUM(CASE WHEN side='SHORT' THEN size_usd ELSE 0 END) as short_liq
FROM liquidation_events
WHERE timestamp > NOW() - INTERVAL '7 days'
GROUP BY hour, market
ORDER BY hour;
Step 5：扩展 — 预测性清算预警（AI 增强）
预测性清算预警系统：
═══════════════════════════════════════
核心思路：
├── 不只是事后报告清算，而是事前预警
├── 监控当前持仓集中度和清算价格分布
├── 预测"如果价格到达 X，会触发多少清算"
└── 帮助交易者和风控团队提前准备
数据输入：
├── 各协议公开的持仓数据
├── 清算价格分布（部分协议公开）
├── 市场深度和流动性
├── 历史清算模式
└── 链上大额转入/转出（准备交易信号）
模型输出：
├── 清算热力图：每个价格点的预估清算量
├── 连锁清算概率：当前市场的级联风险评分
├── 清算猎杀预警：清算密集区接近当前价时告警
└── 保险基金压力测试：极端情景下基金耗尽概率
可视化示例（ASCII）：
BTC 清算热力图（向下）：
Price Long Liquidation Volume
$64,000 █ $2M
$63,500 ██ $5M
$63,000 ████ $12M
$62,500 ██████████ $35M ← 清算密集区
$62,000 ████████████████ $68M ← 危险区域
$61,500 █████████ $30M
$61,000 ███ $8M
当前价：$64,200
最近清算密集区：$62,500（距离 2.6%）
风险评级：中等（距离清算密集区 > 2%）
Step 6：面试评分标准
系统设计面试评分标准（100 分制）：
═══════════════════════════════════════
维度 1：需求分析（15 分）
├── 5 分：提出了 3+ 关键问题
├── 5 分：明确了功能/非功能需求
└── 5 分：需求合理、不过度设计
维度 2：规模估算（10 分）
├── 5 分：估算合理、有依据
└── 5 分：从估算推导出技术选型
维度 3：高层架构（25 分）
├── 10 分：架构完整、层次清晰
├── 10 分：组件职责明确、耦合度低
└── 5 分：数据流清晰
维度 4：核心组件（25 分）
├── 10 分：至少 2 个组件有详细设计
├── 10 分：数据模型/算法选择合理
└── 5 分：考虑了边界条件
维度 5：Trade-off 与扩展（25 分）
├── 10 分：分析了 2+ 个关键 Trade-off
├── 10 分：考虑了失败场景和降级方案
└── 5 分：提出了扩展方向
评分等级：
├── 90-100 分：Strong Hire（顶尖候选人）
├── 75-89 分：Hire（合格）
├── 60-74 分：Weak Hire（勉强合格）
├── 40-59 分：No Hire（需要更多准备）
└── <40 分：Strong No Hire
面试问题
Q1：跨链聚合器中，如何保证报价的准确性？
简短回答：三层保障——多层缓存确保数据新鲜度（L1 内存 <1ms、L2 Redis <5ms、L3 链上 <500ms），报价时附带滑点预估和有效时间，执行时用限价单保护用户（实际价格差于报价超过阈值则回退）。
详细回答：
- 数据层：价格缓存 500ms 刷新，WebSocket 订阅链上事件实时更新
- 算法层：路由引擎考虑流动性深度，大额订单自动拆单
- 执行层：用户设置最大滑点，合约级别保护（不满足则回退）
- 监控层：持续追踪报价 vs 执行偏差，偏差 >0.5% 自动告警调优
Q2：清算监控系统中，如何处理极端行情下的数据洪峰？
简短回答：通过 Kafka 缓冲 + 流处理水平扩展 + 降级策略。Kafka 可承受瞬时 10 万+ QPS 的写入；流处理器按协议分片，水平扩展；极端情况下降级非核心功能（如历史查询），优先保障实时告警。
详细回答：
- 缓冲层：Kafka 分区按协议隔离，峰值数据不丢失
- 处理层：Stream Processor 自动扩缩容，按协议分片
- 存储层：Redis 写入优先（实时展示），TimescaleDB 异步批量写入
- 降级策略：极端行情时关闭历史查询 API，只保留实时推送和告警
Q3：45 分钟系统设计面试中如何分配时间？
简短回答：5 分钟需求分析、3 分钟规模估算、10 分钟高层架构、15 分钟核心组件（深入 2-3 个）、7 分钟 Trade-off 分析、5 分钟总结陈述。关键是不要在任何一个环节花过多时间，保持结构化推进。
核心心得
系统设计面试核心要诀：
1. 结构化思维 > 技术深度
└── 面试官看的是你的思考框架，而非具体技术
2. 需求分析是最重要的环节
└── 错误的需求 → 错误的设计 → 全盘皆输
3. Trade-off 分析展现成熟度
└── 没有完美方案，关键是知道取舍
4. 数字说话
└── 规模估算让你的设计有据可依
5. 先广后深
└── 先画完整架构，再深入 1-2 个核心组件
明日预告
Day 120：交易专题总结 — 知识图谱与面试答案集
- 30 天交易专题知识图谱
- 20+ 面试题完整答案集
- 5 份系统设计文档索引
- 关键数据点速查表
- 求职策略与下一步计划