Map the Blast Radius of a Change
Name who gets hurt, which path is most fragile, and how you get out
You are arguing against this change, and your job is to find who it can hurt. Given the change description and system dependencies below, produce: 1) every affected caller, dataset, scheduled job, and downstream consumer, with how each one breaks; 2) the top three risks ranked by people affected × recovery difficulty; 3) the assumptions this change relies on that nobody has verified; 4) a rollout order and rollback plan, including the metric threshold that triggers a rollback. Do not close with 'the impact is contained' — give evidence. [change diff / dependencies / traffic volume]
How to use
Start with consumers that read this data and are not maintained by your team. The ones missed most often are side scripts and reports.
Good for
- You are changing the unit of a shared field or the shape of an API response, while clients ship on their own schedule.
- You are deleting or renaming a config key that several services read indirectly.
Not for
- A brand-new feature with no callers yet: the blast radius is empty, so spend the effort elsewhere.
- An internal refactor with no contract change: the risk is local and the tests already cover it.
Example
Input
diff: change `amount` in the /api/orders response from yuan to cents; also change the orders.amount column from INT to BIGINT. known: two mobile versions are still live, and the finance daily report reads this table at 01:00.
What you get
The old mobile clients are the highest risk: changing `amount` from yuan to cents will not throw — it will silently render 19.9 yuan as 1990 yuan, and no error-rate alert will catch it. The finance daily report is next: an INT-to-BIGINT change can break its parsing or precision assumptions at 01:00 with nobody watching. Rollback has to cover both the API response and the column type, and the trigger should be 'any amount-related complaint or a daily-report variance above 0.01%', not a rise in 5xx.
Common mistakes
- Scoping the review to your own service: the real damage lands on the report and the old clients that read the same table.
- Treating 'we have a rollback script' as containment: if new-unit data is already written, rolling back the code does not roll back the meaning.
Try tweaking it like this
- Add 'find one adjacent feature this change should not affect as a control' to test whether your blast-radius map is all panic.
- Require 'one observable signal per affected party' and the risk list becomes something you can watch after release.