A crypto aggregator's upstream exchange feeds become unreliable during extreme market volatility - the moment users most need them. How should stale data, provider failover, breakers, caching and user-facing warnings interact?

The defining property of this failure

Provider degradation correlates with user demand. The volatility that drives users to the app is the same volatility that overloads the exchanges. So the system is least reliable exactly when it matters most, and capacity planning for average conditions is planning for the wrong scenario.

The layered response

• Multiple providers per asset, with health scored continuously — latency, staleness, deviation from consensus. Failover is per asset rather than per provider, since a provider may be fine for one market and broken for another.
• A staleness bound with a hard behaviour. Data older than a threshold must be labelled as such and, past a second threshold, withheld. A stale price displayed confidently is worse than no price, because users trade on it.
• Circuit breakers that trip on deviation as well as on latency. A provider returning a price far from consensus is failing in a way that a health check cannot see, and it is the most dangerous failure because it succeeds.
• A separation between display and execution. A slightly stale price on a chart is acceptable. A trade executed against a stale price is a loss for someone, so execution must re-validate against a live quote or refuse.

The user-facing decision

Show the degradation. A visible "prices delayed" indicator preserves trust and prevents users acting on bad data; hiding it produces a worse outcome for both parties. In a financial product this is not merely good practice — a user who traded on data you knew was stale and did not disclose has a legitimate complaint.

The corollary is that the degraded state must be a designed part of the interface, not an error screen, because it will be seen regularly.

What must be protected regardless

• Order and withdrawal paths, which have their own capacity and are shed last.
• Balance correctness, which depends on no external provider and must remain exact.
• The audit trail, which must record what price was shown and what price executed — because the disputes that follow a volatile session are resolved from it.

The capacity conclusion

Size for the volatile day, not the average one. In this domain the peak is the design point, the peak is correlated with the dependency's worst behaviour, and the cost of being under-provisioned is measured in customer trust rather than in latency.