cascading-failureslisted

How one slow dependency becomes a total outage: the amplification loop and the four points that close it — retry storms, unbounded queues, thread and connection exhaustion, an inner timeout longer than the outer one. Covers why cutting offered work is usually the first stabilization step in a cascade, metastability sustained by backlog, recovery herds and criticality separation. Use when one dependency's latency rise took down services that never call it, when the dependency recovered and the system did not, when adding replicas mid-incident made it worse, or when queue depth grows while goodput falls to zero. Does not cover the breaker (circuit-breakers), shedding policy (rate-limiting-and-load-shedding), bulkheads (concurrency-limiting-and-bulkheads), retry policy (retries-and-backoff), queue arithmetic (littles-law-and-queueing), replica routing (load-balancing-and-routing), or the fault model (failure-models).
robsonkades/agent-skills · ★ 2 · AI & Automation · score 75

Install: claude install-skill robsonkades/agent-skills

# Cascading Failures ## Purpose A cascade is a loop, not a list of failures. A dependency slows; its callers' threads and connections sit blocked waiting; the callers saturate; _their_ callers slow; retries add load to the already-slow dependency; it slows further. A wide incident is a cascade only when such positive feedback expands or sustains the failure. Name and cut that edge. A shared infrastructure outage or a coordinated bad deploy can create a wide blast radius without such a loop, so topology and timing remain competing hypotheses. The failure this prevents is the intervention that deepens the outage. **During a cascade the system is doing more work than normal and completing less of it** — retries, queued requests whose callers have already given up, connections held by abandoned calls. Common responses—uncontrolled replicas, longer timeouts, more retries—can increase offered load. Stabilization usually starts by reducing admitted work; repairing the trigger or adding warm, usable capacity can also recover the system when it does not amplify the bottleneck. ## Workflow Inspect the deployed JDK/toolchain, server/client libraries, retry owners, queue/pool limits, deadline/cancellation behavior and autoscaling/probe configuration before recommending an API or configuration change. The topology guidance has no Java baseline; the executor reference states its snippet baseline. Preserve project versions. When traces or counters are missing, state the candidate loop