Back to Details

latency-critical-systems

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Latency Critical Systems

延迟关键系统

Use this skill when the user cares about realtime behavior, hot paths, streaming freshness, or execution speed. This includes HFT-like infrastructure, but the skill is engineering-focused. It does not authorize live trading or financial advice.
当用户关注实时表现、热路径、流数据新鲜度或执行速度时，可使用本skill。这包括类高频交易（HFT）基础设施，但本skill聚焦于工程实现，不涉及实盘交易或金融建议。

Split The Metrics

拆分指标

Do not collapse everything into "fast." Track:
  • p50, p95, and p99 latency;
  • throughput;
  • freshness age;
  • queue depth;
  • cache hit rate;
  • provider/API response time;
  • browser render time;
  • correctness under load;
  • failure and retry behavior.
不要将所有需求笼统归结为“快”。需跟踪以下指标：
  • p50、p95和p99延迟；
  • 吞吐量；
  • 数据新鲜度时长；
  • 队列深度；
  • 缓存命中率；
  • 服务商/API响应时间；
  • 浏览器渲染时间；
  • 负载下的正确性；
  • 故障与重试行为。

Map The Hot Path

绘制热路径

Write the path from user/event to final visible state:
text
source event -> provider API -> ingest worker -> queue -> cache -> edge route
-> client stream -> browser render -> user-visible state
Then measure each segment separately.
梳理从用户/事件到最终可见状态的路径：
text
source event -> provider API -> ingest worker -> queue -> cache -> edge route
-> client stream -> browser render -> user-visible state
然后分别测量每个环节的性能。

Optimization Order

优化优先级

  1. Remove unnecessary round trips.
  2. Cache stable reads with freshness metadata.
  3. Batch small calls and writes.
  4. Move compute closer to the data or the user.
  5. Split hot and cold paths.
  6. Apply backpressure before queues grow unbounded.
  7. Use streaming only when it improves freshness or user experience.
  8. Add canaries for stale data, degraded providers, and bad cache state.
  1. 移除不必要的往返请求。
  2. 为稳定读取操作添加带新鲜度元数据的缓存。
  3. 批量处理小型调用与写入操作。
  4. 将计算逻辑移至更靠近数据或用户的位置。
  5. 拆分热路径与冷路径。
  6. 在队列无限制增长前施加背压。
  7. 仅当流处理能提升数据新鲜度或用户体验时才使用它。
  8. 为过期数据、性能下降的服务商以及异常缓存状态添加金丝雀（canary）检测机制。

Verification

验证环节

Use live readbacks when a deployed surface exists:
  • HTTP timing and response headers;
  • provider freshness timestamp;
  • queue or job state;
  • edge/cache state;
  • browser verification for actual UI freshness;
  • logs around retries and degraded mode.
For market-data or execution-adjacent paths, also verify orderbook age, VWAP assumptions, provider status, and kill-switch behavior before calling the path ready.
当存在已部署的服务面时，使用实时回读验证：
  • HTTP时序与响应头；
  • 服务商数据新鲜度时间戳；
  • 队列或任务状态；
  • 边缘节点/缓存状态；
  • 浏览器端验证实际UI数据的新鲜度；
  • 重试与降级模式相关日志。
对于市场数据或与执行相关的路径，在确认路径可用前，还需验证订单簿时长、VWAP假设、服务商状态以及熔断开关行为。

Guardrails

防护准则

  • Do not optimize latency by dropping required validation.
  • Do not hide stale data behind fast cache hits.
  • Do not claim millisecond behavior from client labels without measurement.
  • Do not run live orders, destructive migrations, or customer-impacting deploys without an explicit approval gate.
  • Keep secrets and private payloads out of logs and benchmark artifacts.
  • 不得通过省略必要的验证来优化延迟。
  • 不得用快速缓存命中掩盖过期数据的问题。
  • 未经测量，不得仅凭客户端标签宣称毫秒级性能表现。
  • 未经明确审批，不得执行实盘订单、破坏性迁移或影响客户的部署操作。
  • 不得将机密信息和私有负载存入日志与基准测试工件中。