Coupling
The degree to which one component must know about, or change alongside, another.
Coupling is not binary and it is not always bad — a system of components that know nothing about each other does nothing. What matters is the kind of coupling and how much of it crosses a boundary you intend to change independently.
Useful distinctions: two services coupled by a stable published contract are far more loosely coupled than two coupled by a shared database table, even though both are "coupled". Temporal coupling (A must be up for B to work) is different from and often more damaging than structural coupling. Coupling to an interface is cheaper than coupling to an implementation.
The practical test: if you had to change this component, how many others would have to be deployed at the same time? That number is your real coupling.