How Bad Could It Be?
At its core, risk is a multiplication problem with two factors. Understanding each factor separately before combining them is essential, because conflating them leads to poor prioritization.
1. Likelihood (How Probable Is This Failure?)
Likelihood is the probability that a specific bad event occurs within a defined time window — typically a month or a year. It can be expressed as a percentage, a frequency ("once per quarter"), or a qualitative rating (Low / Medium / High). Some events are near-certainties: a disk will fill up eventually if nobody monitors it. Others are remote: a meteor strike on your data center is theoretically possible but not worth modeling.
Likelihood estimation draws from three sources:
- Historical data: Your incident logs, monitoring alerts, and post-mortems. If your Redis cluster has gone down twice in the last year, that is a concrete data point.
- Industry baselines: Cloud providers publish availability SLAs (Service Level Agreements). AWS S3 promises 99.999999999% annual durability — that is a likelihood estimate you can use directly.
- Expert judgment: When you have no data, experienced engineers estimate based on system architecture, known anti-patterns, and intuition. This is the least reliable source but often the only one available for new systems.
2. Impact / Blast Radius (How Bad Is It When It Happens?)
If the bad event occurs, what is the damage? Impact should be measured in terms the business cares about — not "the service degraded" but "we lost $X in revenue and breached our SLA with three enterprise customers."
| Blast Radius | Example | Business Impact |
|---|---|---|
| Minimal | A single user sees a 500 error on a non-critical page | Negligible — no ticket filed |
| Small | A background job queue backs up for 20 minutes | Delayed notifications, minor SLA risk |
| Medium | An entire microservice goes down for 10 minutes during peak hours | Lost revenue, customer complaints, SLA breach |
| Large | Primary database corrupted, 2-hour recovery | Significant revenue loss, public incident, trust erosion |
| Catastrophic | Permanent loss of customer data, regulatory violation | Lawsuits, fines, existential threat to the company |
The Risk Score:
Multiplying these two factors gives you a comparable score across all risks:
Risk Score = Likelihood × Impact
A high-likelihood, low-impact event (like a flaky unit test failing in CI) may be annoying but tolerable. A low-likelihood, high-impact event (like ransomware encrypting your production database) demands immediate investment in prevention and recovery — even though it "probably won't happen."
Practical example with numbers:
| Risk | Likelihood (per year) | Impact (cost) | Risk Score |
|---|---|---|---|
| Flaky test blocks deploys | 95% | $500 (engineer time) | $475 |
| Database failover fails | 5% | $200,000 (outage + recovery) | $10,000 |
| Data breach via unpatched CVE | 2% | $2,000,000 (fines + reputation) | $40,000 |
The flaky test feels more urgent because you deal with it every day. The data breach feels distant because it has not happened yet. The math tells you where to actually spend your time.
The decision tree below summarizes the four standard responses to a scored risk. One node references ALE — Annualized Loss Expectancy: the yearly cost of a risk after factoring in how often it actually happens (Risk Score × Annual Probability). For now, read it as "expected yearly damage." A later lesson on Value at Risk walks through ALE end-to-end with worked numbers.
When asked "How do you prioritize technical debt?" in an interview, frame your answer using risk scoring. Say: "I evaluate each item by likelihood of causing an incident multiplied by the blast radius of that incident. This gives me a defensible prioritization I can communicate to product managers in business terms, not just engineering intuition." This demonstrates systems thinking and stakeholder communication — two things interviewers value highly.
Key Point: Humans systematically overweight frequent, visible annoyances and underweight rare, invisible catastrophes. This cognitive bias — called the availability heuristic — is exactly why you need to do the math rather than trust your gut. The risk that keeps you up at night is often not the one that will actually hurt you.