A dependency that normally answers in 80ms starts taking eight seconds. What in your service reacts, and in what order?
Answer
Short answer
A timeout shorter than the caller's patience is the only defence that works without cooperation. Retries need idempotency, jitter and a budget or they amplify the outage; a breaker must trip on latency as well as errors; and a bulkhead is what stops one slow dependency consuming every thread.
This is a resilience design question, not a timeout-setting question. Good resilience work sets deadlines, caps retries, isolates pools, and uses circuit breakers so a slow dependency cannot consume the whole service. Weak resilience answers add retries without budgets and amplify the outage. Strong resilience design decides what to degrade, what to fail fast, and how to recover when the dependency becomes healthy again.
Resilience also means choosing the degraded answer before the dependency fails.
Was this answer helpful?
Likely follow-ups
- Your own callers have a two-second budget. How do you allocate it across three sequential downstream calls?
- When is a fallback response worse than an error?
- The dependency recovers but your service stays degraded for twenty minutes. What is holding it there?
- How would you test any of this, given you cannot make the real dependency slow on demand?
Related questions
- One tenant bursts to ten times their normal traffic and every other customer's latency doubles. Your global rate limit was never hit. How would you design for fairness instead?hardAlso on resilience5 min
- Traffic is a hundred times normal and some of it is real customers. What do you drop first?hardAlso on backpressure5 min
- A job queue is backed up four hours and half the jobs are now pointless. What do you drain, and what do you drop?hardAlso on backpressure6 min
- The business says the system must be highly available. How do you turn that into a number, and what does that number cost?mediumAlso on resilience4 min