The Lifetime Problem No One Talks About Until Production
Dependency Injection is one of the most powerful features ASP.NET Core ships out of the box. Most teams adopt it quickly, register their services, and move on. What they miss - and what production incidents routinely expose - is that the lifetime of a registered service is not a configuration detail. It is an architectural decision with concurrency, memory, and correctness implications that compound as systems grow.
The three lifetimes the ASP.NET Core DI container offers - Singleton, Scoped, and Transient - are not interchangeable. Each carries a distinct contract about who owns the instance, how long it lives, and what sharing guarantees (or hazards) it brings. Getting these wrong does not always surface at startup. Many lifetime bugs hibernate quietly in low-traffic environments and explode under concurrent load, during database failovers, or when a new engineer registers a service without understanding the graph it joins.
This guide is for enterprise teams who want a decision framework they can codify in architecture review checklists, code review templates, and onboarding docs - not a beginner walkthrough.
Lifetimes look simple until a captive dependency or a leaked scope surfaces in production. The full DI setup - lifetimes, keyed services, and safe composition - is on Patreon, ready to run. Chapter 1 of the ASP.NET Core Web API: Zero to Production course wires the options pattern and DI cleanly into a real Program.cs, so these lifetime decisions have a concrete reference.
What Each Lifetime Actually Means
Singleton
A Singleton service is instantiated once per application lifetime and shared across every request, every thread, and every consumer that resolves it. The container holds a single instance from the moment it is first resolved until the application shuts down.
The implications are significant. Singletons must be thread-safe because multiple concurrent requests will share the same instance simultaneously. If a Singleton holds any mutable state - a counter, a cache, a configuration value that changes - that state must be protected with thread-safe constructs. Unprotected mutable Singletons are a direct path to race conditions that are extraordinarily difficult to reproduce in non-production environments.
On the positive side, Singletons are the right choice for services that are genuinely expensive to initialize - database connection pools managed by external libraries, compiled regular expressions, in-memory caches, and heavyweight clients like HttpClient (when managed by IHttpClientFactory). The one-time cost of construction is amortized across the application's entire run.
Scoped
A Scoped service is instantiated once per request scope and shared within that scope. In a web application, each HTTP request creates a new DI scope, so each request gets its own instance of every Scoped service. That instance is shared among all consumers within the same request but not across different requests.
Scoped is the natural lifetime for services that carry request-specific state: the current user context, the current tenant identifier, the current unit of work (DbContext is the canonical example), and anything that participates in a per-request transaction. Scoped services are the backbone of consistent data access patterns because every component within a single request works with the same DbContext instance, ensuring change tracking and transaction boundaries behave predictably.
The key risk with Scoped services is the captive dependency problem: a Singleton that takes a Scoped service as a constructor dependency will capture the Scoped instance at the moment the Singleton is first resolved and hold it for the application's lifetime. The result is a Scoped service that effectively becomes a Singleton - stale data, leaked DbContexts, connection pool exhaustion, and thread-safety violations.
Transient
A Transient service is instantiated fresh every single time it is resolved from the container. No sharing occurs - neither across requests nor within a single request. Every call to GetService<T>() or every constructor injection of a Transient service receives a brand-new instance.
Transient is appropriate for lightweight, stateless operations where isolation is more important than efficiency. Validators, mappers, formatters, and strategy implementations with no shared state are natural candidates. The danger with Transient lies in overuse: injecting a Transient service into a Singleton does not cause the Singleton to get a new instance per request - it captures the first instance at Singleton resolution time. Additionally, if a Transient service implements IDisposable, the DI container will track it for disposal at scope end, which means Transient services registered in a Singleton scope will only be disposed when the application shuts down, creating long-lived resource leaks.
The Captive Dependency Trap
The captive dependency is the most dangerous lifetime mistake in enterprise ASP.NET Core applications. It occurs when a service with a shorter lifetime is injected into a service with a longer lifetime.
Concrete scenarios:
A Scoped DbContext injected into a Singleton service - the DbContext is never disposed per request, connection pool slots are held indefinitely, and eventually connections are exhausted.
A Transient service that wraps an external API client injected into a Singleton - the external client instance is held for the application lifetime, which may violate connection lifecycle expectations.
A Scoped ICurrentUserService injected into a Singleton cache - the cache resolves identity once at startup and returns stale identity data to every subsequent request.
ASP.NET Core includes a scope validation check that detects captive dependencies at startup in the development environment (when ValidateScopes is enabled on IServiceProviderOptions). In production, this validation is off by default for performance reasons. Enterprise teams should explicitly enable ValidateScopes: true in all environments, accept the startup-time cost, and treat any captive dependency exception as a blocking defect before deployment.
Lifetime Selection Decision Framework
The right lifetime is determined by three questions:
1. Does this service hold mutable state?
Stateless → Transient or Singleton (prefer Singleton only if construction is expensive)
Request-scoped state → Scoped
Application-wide state that must be thread-safe → Singleton with care
2. What is the construction cost?
Expensive (connection pools, compiled artifacts, heavyweight clients) → Singleton
Negligible → Transient or Scoped
3. What does this service depend on?
A practical rule of thumb that scales well for teams: default to Scoped, promote to Singleton only when cost justifies it, use Transient for stateless utilities. This default prevents the most common captive dependency scenarios because Scoped services can safely consume other Scoped and Transient services.
Lifetime Compatibility Matrix
| Consumer \ Dependency |
Singleton |
Scoped |
Transient |
| Singleton |
Safe |
Captive dependency - never do this |
Captured instance - not truly Transient |
| Scoped |
Safe |
Safe |
Safe |
| Transient |
Safe |
Safe |
Safe |
The two cells to internalize: a Singleton consuming a Scoped service is always a bug. A Singleton consuming a Transient service is not a crash, but the Transient loses its transient nature - it becomes a de-facto Singleton.
Singletons and Thread Safety
Thread safety is non-negotiable for Singleton services. Every request that touches a Singleton is a potential concurrent reader or writer. For immutable Singletons (configuration wrappers, compiled routes, static lookup tables), thread safety is free - immutable objects require no synchronization. For mutable Singletons, the team must choose a synchronization strategy: lock, ReaderWriterLockSlim for read-heavy scenarios, ConcurrentDictionary for dictionary-shaped caches, or IMemoryCache for general-purpose in-process caching (which is itself a thread-safe Singleton).
A pattern that trips up mid-level engineers: using async/await inside a Singleton does not automatically make it thread-safe. Concurrent requests can interleave between await points, and any shared mutable state touched across those points requires explicit synchronization.
Scoped Services Outside of HTTP Requests
Scoped services are tied to a DI scope, not specifically to an HTTP request. BackgroundService workers, Hangfire job executors, and hosted service entry points do not automatically create a DI scope - they run in the root scope, which behaves like a Singleton scope. Resolving a Scoped service from the root scope will throw at runtime (if ValidateScopes is enabled) or silently create a captive dependency.
The correct pattern for background workers that need Scoped services is to use IServiceScopeFactory to create an explicit scope for each unit of work (each job invocation, each batch item, each message processed). This is one of the most commonly missed patterns in enterprise .NET background processing and one of the most common sources of production DbContext and connection pool issues in worker services.
Disposable Services and Container Tracking
ASP.NET Core's DI container tracks disposable services and disposes them when their scope ends. For Scoped and Transient services registered in a Scoped context, this happens at the end of each HTTP request. For Singleton services, disposal happens at application shutdown.
The trap: Transient services registered in a Singleton context (for example, resolved directly from the root IServiceProvider in application startup code, or injected into a Singleton) will be tracked by the root scope and only disposed at shutdown. If those Transient services hold unmanaged resources (open connections, file handles, streams), the application leaks those resources for its entire lifetime.
The mitigation: never resolve Scoped or Transient services from the root IServiceProvider. If startup code genuinely needs a service with a shorter-than-Singleton lifetime, create a scope explicitly, resolve from that scope, use the service, and dispose the scope.
Enterprise Governance Recommendations
Teams managing multiple services and shared platform libraries benefit from formalizing lifetime decisions rather than leaving them to individual engineers at registration time.
Recommendation 1 - Enable ValidateScopes in all environments. The startup cost is negligible relative to the value of catching captive dependencies before deployment. In .NET 8 and later, this is controlled via WebApplication.CreateBuilder options.
Recommendation 2 - Establish per-layer lifetime conventions. Infrastructure services (repositories, DbContexts, external clients) should follow a documented default lifetime by layer. In Clean Architecture setups: Scoped for DbContext and unit-of-work, Singleton for HttpClient-based external clients managed by IHttpClientFactory, Transient for validators and mappers.
Recommendation 3 - Review Singleton registrations in PRs. Any new Singleton registration should trigger a review of its entire dependency graph for Scoped or Transient dependencies. This is mechanical and can be enforced via static analysis or architecture tests using NDepend or ArchUnitNET.
Recommendation 4 - Use keyed services for complex scenarios. .NET 8 introduced keyed service registration, allowing multiple implementations of the same interface to be registered with different keys and different lifetimes. This reduces the temptation to use a Singleton to cache what should be separate instances per context.
Recommendation 5 - Document lifetime decisions at registration. A one-line comment explaining why a service is registered as Singleton versus Scoped is a form of architectural documentation that pays dividends during incident response and onboarding.
When Lifetime Decisions Break Down at Scale
Several patterns in large-scale .NET applications make lifetime management more complex than it appears in examples:
Decorators and wrappers that wrap a service must match or be shorter than the wrapped service's lifetime. A Singleton decorator over a Scoped service is a captive dependency.
Factory-based registrations (AddScoped<IService>(sp => new Service(...))) give the team explicit control but also bypass the container's dependency graph validation. Factories that resolve Scoped dependencies from sp at Singleton construction time will silently create captive dependencies.
Third-party library services often come with undocumented lifetime requirements. EF Core's AddDbContext registers DbContext as Scoped by design. Registering it as Singleton to "improve performance" is a common and serious mistake that leads to concurrent access violations, stale query caches, and transaction boundary failures.
Multi-tenant systems where the tenant context is resolved per request create an implicit dependency: any service that needs the tenant identifier must be Scoped or resolve it from a Scoped service at call time. A Singleton that caches tenant-specific data without partitioning by tenant is a data isolation failure.
Frequently Asked Questions
Q: Can I safely use a Singleton service inside a Scoped service? Yes. A Scoped service can safely take a Singleton dependency. Singletons have a longer or equal lifetime compared to Scoped services, so there is no captive dependency issue. The Singleton instance will be shared across all requests, which is its intended behavior.
Q: Why does ASP.NET Core only validate lifetimes in development by default? The scope validation check traverses the service graph at resolution time, which has a performance cost. Microsoft chose to enable it only in development environments where catching configuration errors is the priority. Enterprise teams should evaluate whether the startup cost is acceptable for production and staging environments - for most applications, it is.
Q: My background worker needs to access the database. What lifetime should my DbContext use? DbContext should always be Scoped. In a background worker that does not have an HTTP request scope, use IServiceScopeFactory.CreateScope() to create a new scope for each job execution, resolve DbContext from that scope, perform your work, and then dispose the scope. Never resolve DbContext directly from the worker's injected IServiceProvider.
Q: Is there a performance difference between the three lifetimes? Yes. Singleton has the lowest allocation overhead because the instance is created once. Scoped creates one instance per request, which is lightweight in modern .NET with efficient allocation patterns. Transient has the highest allocation overhead because it creates a new instance on every resolution. For high-throughput APIs handling thousands of requests per second, Transient services with significant constructor cost can contribute measurable GC pressure. Profile before optimizing.
Q: Can keyed services in .NET 8 replace the need for lifetime decisions? No. Keyed services give you a way to differentiate multiple registrations of the same interface by key. Each keyed registration still requires its own lifetime decision. Keyed services are useful for plugin-style patterns, strategy selection, and avoiding the service locator anti-pattern in multi-implementation scenarios, but they do not change the fundamental lifetime rules.
Q: What happens if I register a service as Transient but it implements IDisposable? The DI container tracks IDisposable Transient services and disposes them when their owning scope ends. In an HTTP context, they are disposed at the end of the request - which is correct. If a Transient service is resolved from the root scope (outside of an HTTP request, or directly from a Singleton), it will be tracked by the root scope and only disposed at application shutdown, effectively becoming a long-lived resource leak.
Q: How do I enforce lifetime rules in a large team without relying on code reviews alone? Use architecture tests. Libraries like ArchUnitNET and NetArchTest allow you to write tests that verify service registration conventions - for example, asserting that no Singleton service depends on any Scoped service. These tests can run in CI and prevent lifetime violations from reaching code review. Supplement with a ValidateScopes-enabled test environment that runs integration tests against the real DI container.
Conclusion
DI lifetime decisions are architectural decisions. The choice between Singleton, Scoped, and Transient is not a detail to be resolved by convention or convenience - it carries concrete implications for thread safety, memory management, data correctness, and system reliability under load. Enterprise teams that codify lifetime selection criteria, enable ValidateScopes across all environments, and incorporate dependency graph reviews into their PR process will catch lifetime bugs before they reach production. Teams that treat lifetime as an afterthought will encounter them in the worst possible moment: during high-traffic incidents when debugging is hardest and business impact is highest.
The framework is simple: default to Scoped, promote to Singleton only when construction cost justifies it, use Transient for isolated stateless utilities, and never let a longer-lived service capture a shorter-lived dependency.
About the Author
Celin Daniel is Co-founder of Coding Droplets with 13+ years of hands-on experience building, shipping, and operating .NET and ASP.NET Core systems in production. The guidance here comes from real projects and production incidents, not theory.
