Request-scoped providers causing Singleton recreation in NestJS DI

Is the Singleton recreated for every request?

Yes. In NestJS the DI engine follows a rule called scope bubbling. When a provider marked Scope.REQUEST is injected into a provider that is otherwise Scope.DEFAULT (the singleton scope), the consumer provider is automatically promoted to Scope.REQUEST. Consequently, a new instance of that provider is created on each incoming request, and any of its own dependencies that were previously singletons are also promoted.

What does this mean for a deep dependency chain?

Consider a chain three levels deep: A (singleton) → B (singleton) → C (request‑scoped). Because C is request‑scoped, B becomes request‑scoped, which in turn forces A to be request‑scoped as well. Every request triggers the DI container to instantiate A, B, and C anew.

Measurable impact

• CPU overhead: The container must resolve the entire sub‑tree for each request, which adds a few microseconds per request in typical setups. Under very high traffic this can become noticeable.
• Memory allocation & GC pressure: Each instance consumes heap space. If the promoted singleton holds large caches or state, the heap grows rapidly, leading to more frequent GC pauses.

Typical benchmarks (e.g., autocannon at 1k RPS) show a 5–15 % increase in latency when a single promoted provider is involved, with GC events occurring roughly twice as often compared to a pure singleton tree.

How to verify in your own app

1. Create a singleton provider that logs a unique UUID in its constructor.

   @Injectable()
   export class MyService {
     constructor() {
       console.log(`MyService instance: ${uuidv4()}`);
     }
   }
   

2. Inject a Scope.REQUEST provider into it.
3. Send two consecutive HTTP requests and observe the console logs. If the UUID changes, the singleton has been promoted.
4. Run a memory profiler (e.g., node --inspect with Chrome DevTools) while generating traffic to watch heap growth and GC frequency.

Mitigation strategies

• Use ModuleRef for dynamic resolution: By injecting ModuleRef into the singleton and calling moduleRef.get(RequestScopedProvider, { strict: false }) inside a method, you can keep the provider out of the constructor and avoid scope promotion.
• Scope the dependency only where needed: Instead of injecting the request‑scoped provider into a singleton, pass the request object (via @Inject(REQUEST)) into methods that need per‑request data.
• Lazy‑load heavy singletons: If the singleton contains large caches, consider moving that logic into a separate module that can be imported on demand or into a request‑scoped provider that owns the cache.
• Profile your specific version: The exact behavior can differ between major NestJS releases. Verify on the version you are running before applying optimisations.

What detail might change the recommendation?

If your application runs on an older NestJS version (pre‑9.x) or uses a custom DI implementation, the scope bubbling rules might differ slightly. Knowing the exact nestjs version will help tailor the optimisation strategy.