Temporal Coupling
A dependency in which one component requires another to be available at the same moment, so the availability of both is required for either to work.
The form of coupling with the most direct operational consequence, and the one least visible in a codebase.
A synchronous call creates it: if service A calls service B during a request, B's availability multiplies into A's. Ten such dependencies at 99.9% each yield 99.0% — seven hours a month, from components that are individually fine.
It is separate from the other kinds and can exist without them. Two services can share no code, no schema, and no deployment, and still be temporally coupled by a single synchronous call.
Removing it is the highest-leverage availability change available, because it removes a dependency from the series entirely rather than making it more reliable. The mechanisms: publish an event instead of calling; queue the work and process it asynchronously; cache the data so the call is not needed on the request path; or accept a stale local copy.
The cost is honest and should be stated: eventual consistency, and a more complex failure model where the work is invisible until it completes.
Where a synchronous call is genuinely required, the mitigations are timeouts, circuit breakers and fallbacks — which bound the damage rather than removing the coupling.