Your app depends on a third-party API that is slow and sometimes down. How do you make your app resilient?
Quick Answer
Wrap the calls with resilience policies: a sensible timeout, retries with backoff + jitter for transient failures, a circuit breaker so you stop hammering a dead service, and a fallback (cached value, default, queued for later). Isolate the calls (bulkhead) so they can't exhaust your thread pool, and make the feature degrade gracefully rather than failing the whole request.
I put resilience policies around the calls. A timeout first — set from the API's real p99, so a slow call fails fast instead of tying up a thread. Retries with exponential backoff and jitter, but only for transient errors and only for idempotent operations. A circuit breaker so that once the API is clearly down, I stop calling it for a cooldown and fail fast, which protects both sides. And a fallback: a cached value, a default, or queuing the work — the whole page shouldn't 500 because one widget's dependency is down. I also bulkhead the calls so a slow third party can't eat my entire thread pool. In .NET that's IHttpClientFactory with Polly or the standard resilience handler, plus monitoring the circuit state.
- Timeout — never wait indefinitely; pick a value from the API's real p99, not its average.
- Retry — only for transient errors (timeouts, 502/503, 429). Exponential backoff with jitter to avoid a retry storm. Don't retry non-idempotent POSTs without an idempotency key.
- Circuit breaker — after N failures, open the circuit and fail fast for a cooldown, then half-open to test recovery. Protects both apps.
- Fallback / degradation — serve a cached response, a sensible default, or queue the work and return “pending”. The user shouldn't see a 500 because a recommendations widget is down.
- Bulkhead — cap concurrent calls to that dependency so a slow API can't consume all your threads/connections.
- In .NET:
IHttpClientFactory+ Polly /AddStandardResilienceHandler(). Monitor the circuit state and error rate.