REQUEST‑scoped Providers vs Custom Parameter Decorators for Per‑Request State

Decision Context

The goal is to decide whether to use NestJS REQUEST‑scoped providers or custom parameter decorators for handling request‑local data such as authenticated user identity.

Constraints include concurrent HTTP request handling, lifecycle management, and coupling between services. REQUEST‑scoped providers instantiate a new object per request and dispose of it after the response, while parameter decorators extract request metadata directly from the ExecutionContext without creating additional objects.

Uncertainty remains around how each approach propagates context into deeply nested services, the impact on garbage‑collection pressure under high concurrency, and compatibility with non‑HTTP contexts such as WebSocket or microservice message handling.

Specific questions:

• When should REQUEST‑scoped providers be preferred over custom parameter decorators for request‑local state?
• How does NestJS propagate a REQUEST‑scoped provider into nested services, and what errors arise if a singleton service depends on it?
• What are the measurable performance differences between the two approaches under sustained concurrent traffic?