Cross-Cutting Concern
A responsibility that legitimately appears throughout a system rather than in one module, such as logging, authorisation, tracing or transaction management.
Separation of concerns says each module should address one thing. Cross-cutting concerns are the category that resists this: they are needed everywhere, and scattering their implementation through every module is exactly the duplication and tangling the principle exists to prevent.
The usual set: logging, metrics and tracing, authentication and authorisation, transaction management, caching, retry and resilience policy, validation, and audit.
The mechanisms for handling them, in roughly increasing distance from the code: middleware or interceptors in the request pipeline; decorators and aspects; a shared library applying the policy consistently; and infrastructure — a service mesh sidecar or a gateway — which handles it outside the application entirely.
The trade to be explicit about: moving a concern out of the code makes it consistent and invisible, and invisible behaviour is harder to debug. An engineer reading a handler cannot see that a retry policy, an authorisation check and a trace span surround it. That is usually a good exchange, and it is the reason a mesh introduces a new vocabulary of failure.
The judgement is which concerns are genuinely uniform. A policy that needs per-endpoint variation is not cross-cutting; forcing it into middleware produces configuration that is more complex than the code it replaced.