A travel platform depends on hundreds of external suppliers with varying reliability. How should resilience testing be designed when the failures originate outside the system?

Why external dependencies need a different approach

You cannot make a supplier fail on demand. So resilience testing must inject the failure at your own boundary — in the adapter layer — simulating what the supplier would do.

That is an advantage rather than a limitation: it means the tests are safe, repeatable, and can simulate failure modes real suppliers exhibit rarely but consequentially.

The failure modes to inject

Ranked by how often they cause real incidents, rather than by how obvious they are:

1. Slow, not down. The most damaging and least tested. A supplier responding in 8 seconds instead of 200 ms holds threads and connections across the fan-out. Error-rate-based circuit breakers do nothing, because nothing is erroring.

2. Partial or truncated responses. Valid-looking data with fields missing. Tests whether the adapter defaults silently — turning a supplier data problem into a platform correctness problem nobody can attribute — or rejects explicitly.

3. Stale data. Prices and availability that are correct-looking and out of date. Tests whether booking re-validates against the supplier of record rather than trusting the search index it was reached from.

4. Intermittent failure. Alternating success and failure, which is what actually causes circuit breakers to flap and retry logic to amplify.

5. Sudden rate limiting. A supplier that was fine begins rejecting. Tests backoff behaviour and whether the platform respects a Retry-After or hammers.

6. Correlated failure. Several suppliers degrading at once — a shared upstream, a regional network event. Tests whether the aggregate deadline and thread pools hold when many participants are slow.

What the tests must assert

Not merely "the system did not crash". The assertions that matter:

• The global deadline was respected and partial results were returned.
• The user-visible experience was acceptable — results shown, marked appropriately.
• The failing supplier was isolated — other suppliers' latency and success rates unaffected.
• Telemetry attributed the failure correctly, so an operator could identify the supplier.
• No incorrect data was published as a result of partial or stale input.

That third assertion — isolation — is the most valuable one, because per-supplier bulkheading is what prevents one supplier's bad day from becoming a platform outage.

Making it continuous

Run these in production against a small traffic percentage, continuously. Two reasons: resilience regressions are introduced by ordinary changes rather than by carelessness, and a fallback path that is exercised continuously is one that works. Fallbacks held in reserve do not work when needed — which is the most reliable finding in all of resilience engineering.