Skip to main content
ArcSight

Architecture problems / Blast Radius

What is blast radius — and how far does a small change travel?

Blast radius is how many modules can be affected downstream when a given module changes — direct dependents plus transitive impact through the dependency graph.

Low fan-in does not mean low risk. A module with modest imports can still sit on paths that reach most of the codebase.

How ArcSight detects this

Many visitors land here from search — not the homepage. Run this workflow locally on your repo.

  1. 1arc impact

    See how far a one-file change travels downstream through the dependency graph. Example path from Next.js proof.

    arc impact src/server/config-sharedDocs →
  2. 2arc hotspots

    Rank modules by downstream reach — where does change travel farthest?

    arc hotspots
  3. 3arc explain

    Inspect src/server/config-shared — hub role, dependents, and path narrative.

    arc explain src/server/config-shared
  4. 4arc watchPro

    Pro: keep architecture clean after merge so this problem does not return.

    arc watchDocs →
  • Run arc impact on the path you plan to change — structured blast radius is a first-class output field.
  • Compare blast radius across candidate refactor targets before choosing which module to split.
  • Pair blast radius with fan-in: high on both is a merge bottleneck.

Found the issue?

Use arc impact before you change code — structured blast radius and break paths before merge. Use arc watch (Pro) to stop the problem from returning after you fix it.

All problems · Repository proofs · Install

Why it matters

Blast radius answers “what breaks if I change this?” It is a reach signal: core renderer and config paths are supposed to touch many modules. Merge risk appears when blast radius surprises you — a diff that looks local but retraces hundreds of modules.

What it looks like in codebases

  • A small config tweak that invalidates hundreds of build-time modules.
  • Shared renderer or router code where one signature change ripples across app and server layers.
  • Refactors that look local in git diff but touch most of the monorepo in the dependency graph.

Real repository evidence2 proofs

Every row below comes from an ArcSight analysis snapshot — not a template or keyword page.

Next.js

Largest blast radius in this snapshot: 423 modules downstream from src/server/config-shared. Example break path: src/server/config-shared → src/server/request-meta → src/server/request/params. A one-file edit there can retrace a large share of the 1,942-module graph.

ArcSight traced 1,942 modules and 4,489 edges in Next.js (packages/next).

  • src/server/config-shared423 modules· fan-in 46 · CRITICAL
  • src/types423 modules· fan-in 21 · CRITICAL

Inspect first: src/server/config-shared · src/types

Full repository proof: /repositories/nextjs/

Nx

Largest blast radius in this snapshot: 478 modules downstream from src/utils/fileutils. A one-file edit there can retrace a large share of the 589-module graph.

ArcSight traced 589 modules and 2,843 edges in Nx (packages/nx).

  • src/utils/fileutils478 modules· fan-in 71 · HIGH
  • src/utils/workspace-root476 modules· fan-in 112 · HIGH
  • src/utils/versions467 modules· fan-in 21 · HIGH
  • src/native465 modules· fan-in 64 · HIGH
  • src/utils/path454 modules· fan-in 26 · HIGH
  • src/config/task-graph453 modules· fan-in 38 · HIGH
  • src/config/nx-json452 modules· fan-in 123 · HIGH

Inspect first: src/utils/fileutils · src/utils/workspace-root · src/utils/versions

Full repository proof: /repositories/nx/

What to inspect first

  • Modules with blast radius in the hundreds on production graphs.
  • Chains listed in arc impact break paths — the first hop is rarely the only hop.
  • Subsystem boundaries: does blast radius cross team ownership lines?

What to do next

  • Shrink blast radius with explicit interfaces before changing hub implementations.
  • Stage refactors: impact → boundary → re-impact until radius is proven acceptable.
  • Document merge hold criteria when blast radius exceeds your test coverage envelope.

Install · Validation · Repository proofs