DEV Community

Cover image for How to Assess the Blast Radius of a Code Change
Parsa Mohammadi
Parsa Mohammadi

Posted on Originally published at tomosu.ai AI-assisted

How to Assess the Blast Radius of a Code Change

A code change can be small in lines of code and large in production impact.

That is the basic idea behind blast radius.

The blast radius of a change is the set of systems, components, users, or business functions that could be affected if the change behaves unexpectedly.

Start with the changed component

Identify exactly what the pull request modifies.

Then ask:

  • Is it shared?
  • Is it customer facing?
  • Is it part of a critical workflow?
  • Does it interact with a database?
  • Does it handle authentication?
  • Does it control infrastructure?

Map direct dependencies

Find the components that directly depend on the changed code.

Then look one level further.

Changed component
      ↓
Direct dependencies
      ↓
Dependent services
      ↓
Customer workflows
Enter fullscreen mode Exit fullscreen mode

The goal is to understand propagation.

Look at indirect impact

Some changes affect components that don't appear in the pull request.

For example, changing a shared API contract can affect multiple services even when those services are untouched.

That is why dependency mapping matters.

Check production usage

Not every dependency has equal importance.

Ask:

  • How heavily is it used?
  • Which customers depend on it?
  • Which workflows rely on it?
  • Is it part of a critical path?

A shared component with low production usage may have a smaller practical blast radius than a heavily used component.

Look at history

Previous incidents can reveal where changes have caused problems before.

Also look at recent changes and regressions in the same area.

Consider the deployment

Blast radius also depends on how a change is deployed.

A gradual rollout, feature flag, or quick rollback can limit the impact of a failure.

Diff size is not blast radius

A useful rule is:

Lines changed ≠ production impact

A five line change to a shared authentication library can matter more than a 500 line change to an isolated internal tool.

Where PRI fits

The Production Reliability Index (PRI) can use change context, dependencies, production signals, and other reliability evidence to help surface changes that deserve additional attention.

Run a PRI assessment:

https://tomosu.ai/start

Top comments (0)