Classify the dependency first
| Class | On provider failure | Example |
|---|---|---|
| Critical, no alternative | Fail the request honestly | Payment authorisation at checkout |
| Critical, alternative exists | Fail over to second provider | Email and SMS sending |
| Important, deferrable | Queue and retry later | Receipt email, webhook delivery |
| Enhancing | Degrade silently | Recommendations, avatars, analytics |
Most incidents where a minor dependency took down a product trace to a dependency in the bottom row being treated, in code, as if it were in the top row - usually because nobody ever classified it and the default was a blocking call with no timeout.
The controls, in order of value
- Timeouts on everything. An unbounded call is the single most common cause of cascading failure; a hung dependency silently consumes every worker. Set a timeout shorter than your own SLA.
- Circuit breaker. After a failure threshold, stop calling for a cooldown and fail fast, then let a single probe test recovery. This protects both you and the struggling provider.
- Bulkheads. Separate connection pools or worker groups per dependency, so one saturated provider cannot consume the capacity the others need.
- Fallback path, defined in advance: cached value, default value, queue for later, or honest error - and which one, for each dependency.
Multi-provider: the real costs
A second provider sounds like the obvious answer and is frequently the wrong one. The honest accounting:
- An abstraction layer that fits both, which usually means the intersection of their features - you lose whatever is unique to each.
- Divergent behaviour: different error taxonomies, rate limits, webhook formats, data shapes, and consistency guarantees.
- Untested paths rot. A failover route exercised only during incidents will not work during an incident. Either route a small share of live traffic to it continuously, or accept that it is decorative.
- Double the integration surface for compliance, credentials, monitoring and upgrades.
It is worth it for high-volume commodity services where providers are genuinely interchangeable - email, SMS, object storage. It is rarely worth it for anything with deep product semantics.
What to monitor
- Per-provider error rate and latency percentiles, separate from your own.
- Circuit breaker state transitions as events, since a breaker opening is the earliest signal of a provider problem.
- Queue depth for deferred work, which reveals a provider degrading before users notice.
- Fallback invocation count - if it is always zero, you have not verified the fallback works.
The retry mechanics that sit underneath this are in retry strategies and backoff, and the broader architecture in microservices interview questions.
Where CoPilot Interview fits
Disclosure: we build an interview assistant, so treat this as a disclosed pitch. CoPilot Interview is a native Windows and macOS app that puts suggested answers on your own screen in about two seconds, across coding, system design and behavioral rounds, with a permanent free tier that needs no credit card.
Frequently asked questions
How do you handle a third-party API outage?
Classify the dependency first: critical with no alternative fails honestly, critical with an alternative fails over, deferrable work queues for later, and enhancing features degrade silently. Then apply timeouts, a circuit breaker, bulkheads and a pre-defined fallback for each.
What does a circuit breaker do?
After a failure threshold it stops calling the dependency for a cooldown period and fails fast, then allows a single probe request to test recovery before reopening. It protects your own workers from being consumed by a hanging dependency and protects the struggling provider from continued load.
Is it worth integrating a second provider for redundancy?
For high-volume commodity services where providers are genuinely interchangeable - email, SMS, object storage - often yes. For anything with deep product semantics, rarely, because the abstraction collapses to the intersection of both feature sets and the failover path rots unless it carries continuous live traffic.
What is the most common cause of cascading failure?
A call without a timeout. A hung dependency silently occupies every worker or connection until the whole service stops responding, which is why timeouts shorter than your own SLA are the highest-value control before circuit breakers or bulkheads.
Walk into the round with a second pair of eyes
CoPilot Interview is a native Windows and macOS app that puts suggested answers on your own screen in about two seconds, across coding, system design and behavioral rounds. The free tier is permanent: 15 minutes a day, no credit card.
Try it free