What are provider scopes in NestJS and when would you change the default?

Provider scope controls instance lifetime. DEFAULT (singleton) creates one instance for the whole app. REQUEST creates a new instance per incoming request — useful for tenant/user context. TRANSIENT creates a new instance per injection point. Request scope propagates up the dependency chain, which can hurt performance.

Setting provider scope

The three scopes:

1
DEFAULT (singleton) — one shared instance for the app lifetime. Best for stateless services.
2
REQUEST — new instance per request. Use when service needs request context (e.g., tenant ID, user from JWT).
3
TRANSIENT — new instance per injection point. Rarely needed; for stateful utilities.
4
Warning: REQUEST scope propagates — every consumer of a request-scoped provider also becomes request-scoped, impacting performance.

Difficulty: 6/10

Topics: provider scope types, singleton vs request scope, dependency injection lifecycle

Scenario Questions

0-2 years experience

1
You're building a simple API that logs the user ID for each request — you've injected a service that holds the user ID, but it's showing the wrong user across requests. What scope might you have used by accident, and how would you fix it?
2
If you create a service that generates a unique request ID and inject it into a controller, what scope should you use so each HTTP request gets a different ID, and why?

2-5 years experience

1
Your team noticed that some users are seeing other users' data in a multi-tenant SaaS app — you're using a singleton service to store tenant context. What’s likely going wrong, and how would you fix it without rewriting the whole app?
2
A request-scoped database connection provider is causing slow response times under load. What’s the tradeoff between keeping it request-scoped versus switching to singleton, and how would you test the impact?

5-8 years experience

1
You're designing a high-throughput API that needs to cache per-user data, but the cache must be isolated per request to avoid contamination. How would you architect this without hitting memory limits or introducing race conditions?
2
A legacy module uses singleton providers to hold mutable state for request-specific data. You need to migrate to request-scoped providers without breaking existing integrations. What steps would you take to safely refactor this, and what edge cases would you watch for?

8+ years experience

1
Your company is migrating from a monolith to microservices, and several shared libraries rely on singleton providers holding request context. How would you redesign the dependency injection layer to support both environments without forcing every team to rewrite their code?
2
You're evaluating whether to enforce request-scoped providers across 50+ services to prevent state leakage. What are the operational, performance, and maintenance tradeoffs, and how would you convince engineering leadership to adopt or reject this standard?

Follow-up Questions

❓How would you debug a memory leak caused by incorrect scope usage?
❓What happens if you inject a request-scoped provider into a singleton?
❓Can you give an example where using transient scope would hurt performance?