ReliabilitydebuggingAdvanced

Three retries at three layers finished off the payment provider

Symptoms

  • The payment provider became slow (p99 from 180 ms to ~8 s). Four minutes later checkout availability was 2%.
  • Outbound requests to the provider rose from ~420 rps to ~11,000 rps while checkout traffic stayed flat at ~400 rps.
  • The provider returned 429, then temporarily blocked our API key for "abusive traffic".
  • Recovery required turning checkout off entirely for ten minutes; turning it back on at full traffic immediately re-triggered the storm.
# rps per hop (1-minute averages)
time    checkout   gw→checkout   checkout→payment   payment→provider   provider p99
19:58   410        410           415                420                180 ms
20:00   408        612           1,540              3,900              2,100 ms
20:01   405        1,190         3,540              9,870              8,200 ms
20:02   402        1,206         3,610              10,480             timeout
20:03   398        1,210         3,630              10,900             429

# retry configuration, as deployed
gateway.yaml        upstream.max_attempts: 3   on: [5xx, timeout]   backoff: none   timeout: 10s
checkout-svc        http.maxAttempts: 3        on: [5xx, timeout]   backoff: none   timeout: 30s
payment-svc         provider.maxAttempts: 3    on: [5xx, timeout]   backoff: 100ms fixed   timeout: 60s
payment-svc         circuitBreaker.enabled: false     # "disabled after false trips, 2026-03"

Investigate

Inspect areas in any order (0/7 inspected). When you think you know the root cause, commit to it.

Provider status
Recent deploys
Retry configuration at each layer
Circuit breaker on the provider client
Timeout nesting
Payments database
Provider rate limit