What if a component becomes unavailable?

Concentration changes the shape of risk

The Bank of England highlights that reliance on a small number of AI providers could affect financial services when those providers fail, especially if migrating to alternatives is difficult. The analysis addresses the financial system; it does not show that every shared dependency will produce a systemic failure.

For the product team, the question can be very concrete: which journeys depend on this query, this provider, or this model? A vendor inventory falls short if it doesn't reveal which services stop working when one piece goes down.

Reference: Bank of England · AI and financial stability ↗

A failure doesn't always have the same consequence

An information lookup can be postponed. A payment operation may be pending confirmation and should not be retried without checking its status. A signature failure may prevent the formalization from being completed, even though other parts of the dossier remain available.

These situations call for different responses. The contract needs to make it visible whether there was a rejection, unavailability, expiration, or an unknown result. The interface reflects this distinction so the user is not prompted to repeat an action that may already have taken place.

An alternative is not an equivalent

An adapter can isolate a provider's specifics, but it does not guarantee an immediate switch. An alternative needs to deliver the required fields, preserve meaning, and meet operational requirements. Authentication, limits, timeframes, and effects may also change.

Testing an alternative means verifying the entire journey. A technically valid response may carry different semantics. Vendor selection must account for this switching cost and the real conditions for activating a secondary route.

Measure recovery as product work

A useful exercise picks one dependency and observes how the journey behaves without it. Who gets notified? Can the case wait? Which action is blocked? How does the work return to the flow once the service recovers?

This conversation brings architecture, operations and customer service closer together. The goal is not to promise zero failures, but to avoid ambiguous states and improvised recovery. Continuity needs owners and recovery criteria, just as a feature has acceptance criteria.