Mitigating risk from an unproven external dependency?

WHAT THIS TESTS Whether you treat every external dependency as something that will eventually be slow or down, and design the blast radius accordingly rather than trusting the happy path.

A GOOD ANSWER COVERS Start with timeouts on connect and read so a hung dependency releases resources quickly instead of pinning threads or connections. Add a circuit breaker that trips open after a failure threshold, short-circuiting calls for a cooldown so you fail fast and let the dependency recover, then half-opens to probe. Apply the bulkhead pattern by isolating the dependency in its own thread pool or connection quota, so its saturation cannot starve unrelated requests. Define a fallback: serve a cached or stale value, a sensible default, or a degraded but functional experience, and make it explicit what the user sees. Where the feature allows, move the call off the synchronous request path entirely, queuing it or precomputing results. Retries with backoff help for transient blips but must be bounded.

COMMON WRONG ANSWERS Relying on retries alone, which amplifies load on a struggling dependency. No timeout, so slow calls accumulate and exhaust the thread pool. A circuit breaker with no fallback, which just turns slowness into hard errors with no graceful path. Ignoring resource isolation, letting one bad dependency take down the whole service.

LIKELY FOLLOW-UPS How do you tune the breaker thresholds. What does the degraded experience look like to users. How do timeouts interact with retries to avoid retry storms. How do you test these paths.

ONE CONCRETE EXAMPLE A new recommendations API powers the homepage rail. You set a 200ms timeout, wrap it in a circuit breaker that opens after a 50 percent error rate, and isolate it in a dedicated pool. When the API degrades, the breaker opens, calls fail in under a millisecond, and the page renders a cached default rail. Users see slightly stale recommendations instead of a broken or hanging homepage.