A fallback strategy defines the conditions that trigger a change from a primary option to a secondary one. The goal is to maintain acceptable behavior during outages, errors, or degraded performance.

In software and APIs, fallbacks can include switching to a backup provider, using cached data, or returning a simplified response. The fallback choice is usually designed to be lower risk, even if it is less complete or less timely.

A good fallback strategy also covers recovery. It specifies when and how to return to the primary path, and how to prevent rapid switching back and forth.

Why It Matters

Without a fallback strategy, a single failing dependency can cause a full service outage. With one, you can reduce downtime and protect user workflows when problems occur.

How does a fallback strategy work in an API integration?

In an API integration, the client monitors for failures such as timeouts, error codes, or invalid responses. When a trigger condition is met, the client routes requests to an alternate source or changes behavior, such as using cached results. It should also log the event and apply limits to avoid overwhelming the backup path. After stability returns, the client can gradually move traffic back to the primary API.

What is the difference between a fallback strategy and a retry policy?

A retry policy repeats the same request to the same dependency, usually with limits and backoff. A fallback strategy changes the dependency or the output, aiming to keep the system usable even if the primary cannot succeed. In practice, systems often try limited retries first and then fall back if the problem persists. Separating the two helps you control latency, cost, and the user experience.

What should you consider when designing a fallback strategy for market data?

Start by deciding what “good enough” data looks like during an incident, such as slightly older prices or fewer fields. Define freshness rules, for example a maximum age for cached quotes, and communicate that state to downstream users. Ensure the fallback path is tested and has capacity, including rate limits and monitoring. Finally, define a safe return-to-primary process so you do not introduce instability during recovery.

Real-World Example

A trading dashboard normally loads live crypto prices from its primary data provider. If requests begin timing out, the app switches to showing the most recent cached prices from the last successful update and displays a “data may be delayed” note. Once the primary provider responds reliably again, the dashboard resumes live updates.

Fallback Strategy and CoinAPI

When building a fallback strategy for pricing and exchange data, CoinAPI’s Market Data API can be used as a reliable primary or secondary source. You can configure your system to switch to CoinAPI during provider issues, while keeping consistent symbols and normalized responses across exchanges. This helps you maintain continuity even when individual venues or upstream services are unstable.