🔒 Paid
Dependency Timeout Cascade
Service C, the deepest dependency behind the API, Service A, and Service B, has slowed down sharply. Each hop above it keeps its own timeout, and none of them were ever proportioned against the others, so blocked threads and connections are accumulating from the bottom of the chain upward. The capability Service C provides is not considered critical enough to justify indefinitely blocking every service above it, and customers should see fast, clear failures rather than long hangs. Diagnose which hop is actually accumulating pressure and bring the chain back to a durable, sustainable state.
- Difficulty
- Staff
- Expected Time
- ~20 min
- Category
- Microservices & Dependencies
Skills
- Reasoning about timeout budgets across multiple chained services
- Recognizing retry amplification against a uniformly slow (not flaky) dependency
- Distinguishing a re-proportioned fix from a dependency fenced off with a circuit breaker
- Identifying which subsystem a mitigation's pressure actually transfers to next
System Architecture
- Client
- API
- Service A
- Service B
- Service C
This is a Pro scenario. Upgrade to Pro to unlock it.
Upgrade to ProBack to Incidents