There's a decision I've gotten wrong more than once: adding retry as if it were a free improvement. Configure three attempts with exponential backoff, the system looks more stable on the dashboard, done. What I wasn't watching was how many extra calls I was sending to the downstream on every failure.

This post comes from an experiment I built to measure exactly that: when retry buys real availability, when it multiplies pressure, and when it simply changes nothing because the problem isn't transient. The repo is retry-resilience-experiment , commit bdfc350 , with Spring Boot 3.3.5, Java 21, Resilience4j 2.2.0, and k6 as the load generator.

My thesis is simple: retry is budget. Each extra attempt consumes user wait time, hits the real downstream, and can accelerate a degradation that was already in progress. It's not a feature you flip on and call it done.

The problem with only looking at success rate

When the downstream has simulated random failures at 35%, the difference between policies is visible.…