Retries change the load that changes their failure probability

Assume each failed attempt independently triggers one next attempt, with constant failure probability p and at most N total attempts. Expected attempts are 1+p+⋯+p^(N−1), because attempt j occurs only if all previous ones failed. This model ignores backoff scheduling, deadlines, cancellation, and load-dependent outcomes. It is useful for an initial capacity estimate, but successful delivery is not the same as exactly-once business effect. A timeout can follow a committed action, so every retried state-changing request still needs a compatible identity and effect contract.

Layered retries multiply worst-case work. If three layers each allow three attempts of their child operation, one original action can trigger up to 27 leaf attempts under the full nested retry path. A global retry budget or a single intentional retry layer makes that amplification easier to reason about. Include attempts already in flight when cancellation arrives; sending a cancel signal does not instantly reclaim their server CPU. Measure original operations, attempts, accepted work, and completed useful results separately so extra traffic is not mistaken for healthy demand growth.

Multiply original operation rate by expected attempts to estimate offered attempt rate under the fixed-probability baseline. Compare that rate with usable service capacity. When the estimate exceeds capacity, a stable low-delay interpretation is no longer credible without admission control, rejection, or changed behavior. Failure probability can rise with queueing and deadline misses, so recalculating with the old p is not self-consistent. The apparent retry improvement can therefore disappear precisely when many callers try it at once. Shared backends can propagate the overload to otherwise healthy callers.

An unlimited branching toy makes one instability condition visible: if every failed attempt produces m descendant retries on average, expected offspring is mp. The expected total family is finite only below one under the idealized independent branching assumptions. Real systems have attempt caps and deadlines, so this is not a literal claim that production generates infinitely many requests. Finite caps can still permit a damaging burst or sustain offered work above service. A feedback analysis must include arrival timing, resource retention, failure dependence, and what work continues after callers have given up.

Backoff delays attempts, jitter reduces synchronization, and retry caps bound attempts per operation. None creates service capacity or guarantees a safe side effect. Admission control, load shedding, bounded queues, and retry budgets can prevent low-value attempts from consuming the recovery headroom. Propagate end-to-end deadlines so a downstream retry does not restart the user's clock, and avoid retrying deterministic invalid input. Validate behavior during a recovery ramp: many queued clients becoming eligible together can recreate overload after the original fault has gone away.

The queue lab isolates offered-rate pressure without retry generation. For EACH run Reset, set BOTH rates, predict, then Play or Step: compare (λ,μ)=(4,3) and (2,3). Starting from backlog four at t=0, one grows and the other drains by four seconds. Edits retain t and recompute from four rather than a live policy change. There is no branching, backoff, deadline, cancellation, or load-dependent failure probability. Use the worked amplification calculation to choose a hypothetical offered rate, and use the queue only to reason about the resulting constant-rate imbalance.