Correlated Degradation
also called Demand-Coupled Failure, Peak-Correlated Dependency Risk
The condition where a dependency's reliability worsens for the same reason that user demand rises, so the system is least capable exactly when it is most needed.
Most capacity planning assumes demand and dependency health are independent. In several domains they are not: the event that drives users to the product is the same event that overloads the upstream systems.
Market volatility drives trading volume and simultaneously overloads exchanges and data providers. A sporting event drives contest entries and simultaneously loads the payment providers everyone else is also using. A weather disruption drives delivery demand and simultaneously degrades courier and mapping services.
Why it matters
It invalidates the usual planning assumption. Sizing for average conditions, and testing against a dependency behaving normally, produces a system that is measured under conditions it will never fail in. The design point is the correlated bad day, not the average one.
It also changes the value of failover: if all providers degrade together, provider redundancy buys less than expected, and the degradation policy matters more than the redundancy.
Implementation patterns
- Size for the correlated peak, and test with dependencies degraded rather than healthy.
- Score provider health continuously on latency, staleness and deviation from consensus, failing over per asset or per operation rather than per provider — a provider may be fine for one market and broken for another.
- Trip breakers on deviation, not only on errors and latency. A provider returning a plausible wrong value is failing in a way health checks cannot see, and it is the most dangerous case because it succeeds.
- Enforce a staleness bound with hard behaviour: label past one threshold, withhold past a second. A stale value displayed confidently is worse than none when users act on it.
- Separate display from execution. A slightly stale chart is acceptable; an execution against a stale price is a loss for someone, so execution must re-validate or refuse.
- Design the degraded state into the interface, since it will be seen regularly and an error screen is the wrong artefact.
Industry example
Crypto aggregators such as CoinSwitch and CoinDCX experience this most sharply: extreme volatility brings maximum user demand and maximum upstream unreliability at the same moment, and the products' value depends on data whose quality is worst precisely then.
The same coupling appears in brokerages at market open, in payment platforms during a national sale event, and in delivery platforms during severe weather.
Failure scenarios
- Capacity sized for average, so the correlated peak is the first real test.
- Testing with healthy dependencies, which validates a scenario that will not occur.
- Provider redundancy assumed to help, when all providers degrade together.
- Stale data served without disclosure, which in a financial product produces a legitimate customer complaint rather than a technical issue.
- Health checks that cannot see a wrong-but-successful response.
Trade-offs
Sizing for the correlated peak means substantial capacity idle most of the time, and testing against degraded dependencies is more work than testing against healthy ones.
The counter-argument is that the correlated peak is when the business is made or lost — it is the highest revenue and the highest reputational exposure — so the arithmetic favours the capacity. The judgement is sharper for products where the peak is a large share of activity and softer where the peak is marginal.
Interview question
"Your data providers are slowest during exactly the market conditions that bring you the most users. What changes in your capacity plan, your testing, and what the user sees?"