Dependency fan-in

What it means

Dependency fan-in measures how many callers, modules, or services rely on one component. High fan-in can indicate a valuable shared abstraction, but it also increases the potential blast radius of a change. Interpret it with interface stability, ownership, test depth, and actual usage frequency rather than assuming that more consumers is automatically bad.

Example

A date utility is imported by nearly every service. Its fan-in makes a signature change expensive, so the team adds a compatibility layer and coordinates consumers before removing the old API.

Limitations

Static imports can overstate real runtime use, while dynamic calls can be missed. A widely used stable interface may be safer than a low-fan-in component with privileged access. Define whether generated and test-only consumers count.

How to use the signal

Weave can place high fan-in changes beside pull request size, review load, and rework. That helps teams prioritize coordination where the delivery evidence suggests risk, while dependency ownership remains in the repository tooling.