DI scopes and lifecycles: singleton, request, transient

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.

Together these three lifetimes map the full cost spectrum: singleton amortizes construction to zero per request, request scope pays one allocation per request, and transient pays one per injection site. The wrong choice in either direction — singleton holding state, or request scope bubbling — turns that cost into a correctness bug.

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.

Put numbers on it. A singleton is constructed once, ever — zero per-request allocations on the wiring axis. Flip one low-level provider to request scope and bubble it through a 10-deep controller subgraph, and now the container runs ~10 constructor calls and allocates ~10 objects per request. At 5,000 req/s that is 50,000 short-lived objects per second the GC must reclaim; in a NestJS service this commonly shows up as a few hundred microseconds to ~1ms added at p99 and a visibly busier young-generation GC. Worse is the request-scoped leak: if a request-scoped provider registers a listener, opens a handle, or pushes into a module-level array and nothing tears it down at request end, each request leaves residue behind. A handler that subscribes to an EventEmitter per request without unsubscribing can grow heap on the order of tens of MB/hour under steady load — a slow leak that looks fine in a 60-second local test and OOM-kills the pod at 3 a.m. The senior reflex: request scope is not “free safety,” it is a per-request allocation budget and a teardown obligation.

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.