Dependency Risk Scoring
Every external dependency is a risk. Here's how to evaluate them, prioritise them, and decide when to act.
Your architecture probably contains dozens of third-party dependencies. Not all of them deserve the same attention. Risk scoring lets you answer the real question: which one should I act on first?
Risk = Impact × Probability
Every risk model rests on two axes. Impact measures how badly a failure of this dependency hurts your users: Critical (blocks revenue flows), High (degrades core user experience), Medium (slows secondary operations), Low (cosmetic or non-blocking). Probability follows directly from SLA: 99.9% means ~8.7h of downtime per year, or ~43 minutes per month in expectation.
The blast radius
A critical dependency is not just the one that fails most often — it's the one whose failure triggers the most cascades. A shared authentication service down means all protected endpoints become inaccessible simultaneously. Mapping the blast radius of each dependency often reveals SPOFs (Single Points of Failure) invisible in the usual topology.
Mitigation strategies by tier
Mitigation strategy depends on the tier: Critical without fallback → circuit breaker + graceful degradation (return a cached response or minimal state). High → retry with exponential backoff + aggressive timeout. Medium → simple retry + error log. Low → accept the risk, monitor. An existing fallback reduces the effective risk score even if impact remains high.
Correlated failures: the blind spot
The product law assumes failure independence. In reality, two providers hosted in the same AWS us-east-1 region share a common failure mode. A region outage can simultaneously affect your RDS database, Lambda functions, and several SaaS providers. Risk scoring must account for these correlations — often the only remedy is multi-region or multi-cloud.
Common pitfalls
- Assessing risk without accounting for fallback: a critical dependency with a robust fallback is less risky than a 'medium' dependency with no safety net.
- Treating dependencies as independent: cloud co-locations create invisible correlations that blow up your real risk.
- Running the scoring only once: SLAs change, architectures evolve. An unmaintained risk score becomes misleading within months.
Related articles
Try the simulator →
Dependency Risk Scorer →