Problem Analysis · Experiment Log问题分析 · 实验记录

Diagnosing intermittent 504 errors on the checkout API排查结算 API 间歇性 504 错误

A record of the experiments run to isolate and confirm the root cause.为定位并确认根本原因而开展的一系列实验记录。

Status状态
In progress进行中
Date日期
2026-03-14
Lead负责人
Alex Lin林子谦
Reference编号
INC-2026-014

Objective研究目标

Identify why roughly 3% of checkout requests return a 504 Gateway Timeout during peak hours, by running a series of controlled experiments to isolate and confirm the cause.通过开展一系列受控实验来定位并确认原因,查明为何在高峰时段约有 3% 的结算请求返回 504 网关超时

Environment环境
Production生产环境
Service服务
checkout-api v2.8.1
Date range时间范围
2026-03-12 → 03-14

Experiments实验

Experiment 01实验 01 Reproduce the timeout under controlled load在受控负载下复现超时 Complete已完成
Objective目标
Confirm the 504 can be triggered by load alone, with no code change.确认在不修改代码的情况下,仅凭负载即可触发 504。
[ ▦ ]
Replace with your image请替换为您的图片
<img src="…">
Figure 1.1图 1.1 · Load-test dashboard; errors begin near 200 concurrent checkouts.压力测试面板;约 200 并发结算时开始出现错误。

Chart 1.1图表 1.1 · 504 errors vs concurrent checkouts.504 错误数与并发结算量对比。

500
1000
1501
20014
25033
30058
Conclusion结论Confirmed已确认

Errors begin once concurrency passes ~200 and rise sharply beyond it. The failure is load-dependent and reproducible.并发超过约 200 后开始出现错误,并随之急剧上升。该故障与负载相关且可复现。

Experiment 02实验 02 Isolate the slow upstream定位缓慢的上游服务 Complete已完成
Objective目标
Determine where the 30 seconds is spent — in checkout-api or a downstream service.确定 30 秒的耗时发生在 checkout-api 还是某个下游服务。
[ ▦ ]
Replace with your image请替换为您的图片
<img src="…">
Figure 2.1图 2.1 · Trace waterfall for a failed request.一次失败请求的调用链瀑布图。
[ ▦ ]
Replace with your image请替换为您的图片
<img src="…">
Figure 2.2图 2.2 · Connection-pool wait time during the spike.激增期间的连接池等待时间。
Expected预期
  • checkout-api < 50 mscheckout-api < 50 毫秒
  • payment-service < 300 mspayment-service < 300 毫秒
  • total < 2 s总计 < 2 秒
Actual实际
  • checkout-api ≈ 41 mscheckout-api ≈ 41 毫秒
  • payment-service ≈ 29,900 ms (DB wait)payment-service ≈ 29,900 毫秒(等待数据库)
  • total ≈ 30 s → timeout总计 ≈ 30 秒 → 超时
trace.json
{
  "trace_id": "a1b2c3d4e5f6",
  "spans": [
    { "service": "checkout-api",    "duration_ms": 41 },
    { "service": "payment-service", "duration_ms": 29918, "wait": "db_pool" }
  ],
  "total_ms": 30021
}
Conclusion结论Confirmed已确认

Almost all latency is in payment-service waiting on a saturated database connection pool. The pool is the bottleneck.几乎全部延迟都发生在 payment-service 等待已饱和的数据库连接池上。连接池即为瓶颈。

Duplicate the <article class="experiment"> block above for each additional experiment.为每个新增实验复制上方的 <article class="experiment"> 区块即可。

Overall Conclusion总体结论

Across the experiments, the 504 timeouts are caused by an undersized database connection pool in payment-service that saturates under peak load. The failure is load-dependent (Exp. 01) and localised to the payment-service DB pool (Exp. 02). Increasing pool capacity and adding backpressure is expected to resolve it.综合各项实验,504 超时的根本原因在于 payment-service 的数据库连接池配置过小,在高峰负载下被占满。该故障与负载相关(实验 01),并定位于 payment-service 的数据库连接池(实验 02)。提升连接池容量并引入背压机制有望予以解决。

Next Steps后续行动

  • Increase the payment-service pool 3× and load-test at 2× peak.将 payment-service 连接池容量提升至 3 倍,并在 2 倍高峰下压测。 Owner: Platform负责人:平台组In progress进行中
  • Add an upstream timeout and retry-with-backpressure on checkout-api.在 checkout-api 上增加上游超时与带背压的重试机制。 Owner: Checkout负责人:结算组To do待办
  • Re-run Experiment 01 to confirm zero timeouts after the change.重新执行实验 01,确认改动后超时归零。 Owner: Alex Lin负责人:林子谦To do待办
Confidential · Internal analysis record · INC-2026-014机密 · 内部分析记录 · INC-2026-014
Template — replace the example experiments, images, data, and JSON with your own.模板 — 请将示例实验、图片、数据与 JSON 替换为您自己的内容。