Skip to main content
ArcSight

Architecture problems / Shared Kernel Risk

Draft

Tier 2 problem — exemplar mapping pending.

What is shared kernel risk — and when do shared modules become bottlenecks?

Shared kernel risk appears when multiple teams or subsystems depend on the same core module — a shared kernel — without a stable contract or versioning strategy.

Install ArcSightRun arc impact in under 3 minutesSee example output →

How ArcSight detects this

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

  1. 1arc impact

    Run on the file you plan to change. Surfaces blast radius and break paths.

    arc impact packages/shared/src/indexDocs →
  2. 2arc hotspots

    Rank modules by fan-in and downstream reach across the repo.

    arc hotspots
  3. 3arc explain

    Inspect packages/shared/src/index — hub role, dependents, and path narrative.

    arc explain packages/shared/src/index
  4. 4arc watchPro

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

    arc watchDocs →
  • High fan-in on modules labeled as shared or common in path names.
  • Blast radius crossing team ownership boundaries from one kernel module.
  • Repository proofs listing the same hub across multiple risk signals.

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.

npm install -g arcsightInstall →arc impact docs →arc watch docs →

All problems · Repository proofs · Install

Why it matters

Shared kernels are often intentional, but they concentrate merge risk. One team’s “small fix” becomes another team’s breaking change when the kernel lacks explicit boundaries.

What it looks like in codebases

  • Shared types packages imported by every app in a monorepo.
  • Core config modules touched by server, client, and tooling teams.
  • Internal “platform” utils with no owner and rising fan-in.

Real repository evidence

No indexed exemplar yet. See Next.js repository proof for the current flagship analysis while this problem page is in draft.

What to inspect first

  • Kernel module export surface — stable vs experimental split.
  • Teams or packages that depend on the kernel without integration tests.
  • Versioning or changelog discipline on the kernel.

What to do next

  • Split experimental APIs from stable kernel contracts.
  • Assign explicit ownership to kernel modules with highest fan-in.
  • Require arc impact on every kernel PR.

Install · Validation · Repository proofs