DI scopes and lifecycles: singleton, request, transient

A bug report says user A occasionally sees user B’s account name. The auth code is correct. The leak is a currentUser field on a service that was registered as a singleton — one instance shared by every concurrent request. Request A sets the field, request B overwrites it a millisecond later, and request A reads B’s value. Nobody wrote a security bug. Someone chose the wrong lifetime.

Three lifetimes

A DI container can create an instance at three cadences:

• Singleton — one instance for the whole process, created once and shared by every request. The default in NestJS, Spring, and most containers. Fast and memory-light, because nothing is recreated.
• Request-scoped — one instance per incoming request, shared within that request, discarded after. Useful for per-request context (the current user, a request ID, a per-request transaction).
• Transient — a fresh instance every time it is injected. Useful for stateful helpers that must not be shared at all.

The singleton-with-state trap

The Hook’s bug is the canonical singleton mistake: a singleton must be stateless with respect to a request, because it is shared across all concurrent requests. Storing this.currentUser on a singleton is a data-leak waiting to happen — concurrent requests race on the shared field. The fix is either to make the per-request data flow through method arguments (pass user in, do not store it) or to make the service request-scoped so each request gets its own instance.

The opposite trap: scope bubbling

Request scope looks like the safe default, so teams reach for it — and pay a hidden cost. Scope bubbles up the injection chain: if a request-scoped provider is injected into a controller, that controller becomes request-scoped too, and so does anything that depends on it. One request-scoped logger near the bottom can “infect” the entire graph above it, so the container reinstantiates a large slice of your services on every single request instead of reusing singletons. That is extra allocation, extra GC pressure, and measurable latency — for what is often just a convenience.

Picking the lifetime

The rule that avoids both traps: default to singleton and keep singletons stateless; reach for request scope only when you genuinely need per-request identity that cannot be passed as an argument; use transient sparingly for deliberately unshared stateful helpers. Most “I need the current user here” cases are better solved by passing it through the call than by making the service request-scoped and dragging the whole graph down with it.