advanced
It Got Worse When We Retried
Read the evidence before you read the options. The signals are presented the way a dashboard would present them — nothing is labelled with the answer.
The report
The payments dependency started returning errors at 11:20. Our team enabled aggressive retries at 11:35 to improve reliability. By 11:50 the dependency was almost entirely unavailable and our own error rate was worse than before the retries were turned on.
The system
Checkout API and payments dependency — 11:00 to 12:00ILLUSTRATIVE
| Signal | Value | What it tells you |
|---|---|---|
| User request rate | 1,400 req/s, flat all hour | Actual customer traffic does not change across the window. |
| Provider error rate, 11:20 | 0.2% → 12% | The dependency began failing roughly one call in eight. |
| Our calls to provider, 11:00–11:34 | 1,405/s | One outbound call per user request. |
| Our calls to provider, 11:50 | 4,900/s | Outbound calls are three and a half times user traffic. |
| Provider error rate, 11:50 | 71% | Most calls now fail, up from 12% before retries were enabled. |
| Provider p99 latency | 340 ms → 8.4 s | Calls that do succeed take twenty-five times longer. |
| Our error rate | 11% at 11:30 → 46% at 11:50 | Customer-visible failures roughly quadrupled after retries were enabled. |
| Retry config | 5 attempts, no backoff, no jitter | Each failure produces up to four immediate additional calls. |
What is the constraint?