Lifetime Management - Learning Module

Loading content...

0/246

Choosing Appropriate Lifetimes

The Art of Lifetime Selection

You now understand the three lifetime strategies individually: transient (new each time), scoped (one per scope), and singleton (one forever). The remaining challenge is selection—given a service, how do you determine the correct lifetime?

This isn't always obvious. Make it too short-lived, and you waste resources recreating instances needlessly. Make it too long-lived, and you introduce threading bugs, stale data, or captive dependencies. The right choice depends on analyzing the service's characteristics: its state, its thread safety, its dependencies, and its role in the application.

This page provides a systematic framework for making these decisions. By the end, you'll be able to examine any service and confidently select its lifetime—not by guessing, but by applying clear principles.

What You Will Learn

By the end of this page, you will have a reliable decision process for lifetime selection. You'll understand the key questions to ask, the common patterns that emerge, and how to handle edge cases. You'll also see complete real-world service analyses that demonstrate the framework in action.

The Lifetime Decision Framework

When determining a service's lifetime, ask these questions in order. Each question narrows the options until the correct lifetime becomes clear.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
START: What lifetime should this service have?
 
┌─────────────────────────────────────────────────────────────────────────────┐
│ Q1: Does the service hold PER-REQUEST state?                                │
│     (User context, request ID, validation errors, operation tracking)       │
├─────────────────────────────────────────────────────────────────────────────┤
│ YES → Use SCOPED (or TRANSIENT if needed fresh per injection point)         │
│ NO  → Continue to Q2                                                        │
└─────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ Q2: Is the service expensive to create?                                     │
│     (Database connections, remote config loading, cache warming)            │
├─────────────────────────────────────────────────────────────────────────────┤
│ YES → Prefer SCOPED or SINGLETON (to amortize creation cost)                │
│       Continue to Q3 to decide between them                                 │
│ NO  → TRANSIENT is safe, but continue to Q3 for optimization opportunity    │
└─────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ Q3: Is the service THREAD-SAFE?                                             │
│     (Stateless, immutable state, or synchronized mutable state)             │
├─────────────────────────────────────────────────────────────────────────────┤
│ YES → SINGLETON is an option. Consider Q4.                                  │
│ NO  → Cannot be SINGLETON. Use SCOPED or TRANSIENT.                         │
└─────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ Q4: Should all consumers share the SAME state/data?                         │
│     (Application-wide cache, global configuration, shared metrics)          │
├─────────────────────────────────────────────────────────────────────────────┤
│ YES → Use SINGLETON                                                         │
│ NO  → Continue to Q5                                                        │
└─────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ Q5: Should consumers within ONE REQUEST share the same instance?            │
│     (DbContext, unit of work, request transaction)                          │
├─────────────────────────────────────────────────────────────────────────────┤
│ YES → Use SCOPED                                                            │
│ NO  → Use TRANSIENT                                                         │
└─────────────────────────────────────────────────────────────────────────────┘

When In Doubt

If you're uncertain after the decision tree, default to SCOPED for database-touching services and TRANSIENT for everything else. This is conservative—you might create more instances than strictly necessary, but you won't introduce threading bugs or captive dependencies. Optimize to singleton only when you've verified thread safety.

The Five Key Questions Explained

Let's examine each decision question in depth, with examples of how to answer it for real services.

Q1: Does the service hold per-request state?

Per-request state is data that varies from one request to another and should not leak across requests. Examples:

Current user identity — Each request has a different user
Request correlation ID — Each request has a unique ID for tracing
Validation error collection — Errors from validating THIS request's input
Operation timing — Stopwatch tracking THIS request's duration
Audit trail — Events from THIS request

If the service stores any of this, it must be scoped or transient. Singleton would cause cross-request contamination.

Q2: Is the service expensive to create?

Expensive creation includes:

Network calls — Loading configuration from remote service
Database queries — Initializing lookup data from database
File parsing — Reading and parsing large configuration files
Resource allocation — Establishing connection pools, opening file handles
Complex computation — Pre-computing hash tables, indexes

If creation is expensive, you want to minimize how often it happens. Singleton creates once for the application. Scoped creates once per request. Transient creates every time—expensive.

Q3: Is the service thread-safe?

Thread safety means the service can be used by multiple threads simultaneously without corruption. A service is thread-safe if:

Stateless — No mutable instance fields
Immutable state — Fields are readonly and set only at construction
Concurrent collections — Uses ConcurrentDictionary, not Dictionary
Proper synchronization — Uses locks around mutable state

If not thread-safe, singleton is dangerous—concurrent requests will corrupt internal state.

Q4: Should all consumers share the same state/data?

Some services are valuable precisely because they're shared globally:

In-memory cache — Accumulated across all requests
Feature flags — Loaded once, used everywhere
Metrics — Aggregated from all requests
Configuration — Same settings for entire application

If sharing is the point, use singleton.

Q5: Should consumers within one request share the same instance?

This is about intra-request sharing:

DbContext — Multiple services should share to maintain transaction coherence
Unit of Work — Coordinator for changes within a single operation
Request context — User info accessible by all services handling the request

If services within a request should see the same instance, use scoped. If each injection point should get its own, use transient.

Quick Reference: Common Service Lifetimes

For common service types, the correct lifetime is well-established. Use this table as a quick reference:

Recommended Lifetimes by Service Type
Service Type	Recommended	Rationale
Database Context (DbContext, Session)	Scoped	Transaction coherence, change tracking, not thread-safe
Repository	Scoped	Usually wraps DbContext, shares its lifetime
Application Service	Scoped	Orchestrates per-request operations
User/Request Context	Scoped	Per-request identity, must not leak
Validator	Scoped/Transient	Transient if stateless, scoped if collecting errors
Mapper (AutoMapper)	Singleton	Stateless, expensive to initialize
Configuration Service	Singleton	Read once, immutable thereafter
In-Memory Cache	Singleton	Shared across all requests, thread-safe collections
Logger/LoggerFactory	Singleton	Stateless, thread-safe by design
HttpClient/IHttpClientFactory	Singleton	Connection management, pooling
Feature Flag Service	Singleton	Shared flags, refreshed periodically
Metrics Collector	Singleton	Aggregates from all requests
Email Sender	Transient/Singleton	Transient if simple, singleton with pooling
File Processor	Transient	Each operation gets fresh instance
Document Generator	Transient	Per-operation state

These Are Guidelines, Not Rules

Your specific implementation might differ. An EmailSender that maintains a connection pool is better as singleton. A EmailSender that just constructs SMTP messages is fine as transient. Always apply the decision framework to your specific implementation.

Dependency Lifetime Compatibility

A service's lifetime is constrained by its dependencies. The captive dependency rule states:

A service cannot safely depend on services with shorter lifetimes.

This is because the longer-lived service captures a reference to the shorter-lived one, keeping it alive beyond its intended scope.

Lifetime Compatibility Matrix
Service Lifetime	Can Safely Depend On	CANNOT Depend On
Singleton	Singleton only	Scoped (captive!), Transient (captive!)
Scoped	Scoped, Singleton	Transient* (wasteful, not dangerous)
Transient	Transient, Scoped, Singleton	(all valid)

*Scoped depending on transient is technically safe but wasteful—the transient is created each time the scoped service is injected into some consumer, defeating the "once per scope" optimization.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
// Problem: Singleton depends on Scoped
public class GlobalService // Singleton
{
    private readonly ApplicationDbContext _db; // Scoped - CAPTIVE!
    
    public GlobalService(ApplicationDbContext db) { _db = db; }
}
 
// Solution 1: Make the service scoped too
services.AddScoped<GlobalService>(); // Now safe
 
// Solution 2: Use scope factory (when singleton is actually needed)
public class GlobalService // Singleton
{
    private readonly IServiceScopeFactory _scopeFactory;
    
    public GlobalService(IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
    }
    
    public async Task DoSomethingAsync()
    {
        await using var scope = _scopeFactory.CreateAsyncScope();
        var db = scope.ServiceProvider.GetRequiredService<ApplicationDbContext>();
        // Use db within this scope only
    }
}
 
// Solution 3: Redesign - remove the dependency
public class GlobalService // Singleton
{
    // No DbContext dependency - receives data through method parameters
    public OrderSummary CalculateSummary(IEnumerable<Order> orders)
    {
        return new OrderSummary(orders);
    }
}
 
// Caller (scoped) provides the data
public class OrderService // Scoped
{
    private readonly ApplicationDbContext _db;
    private readonly GlobalService _globalService; // Safe - scoped can depend on singleton
    
    public async Task<OrderSummary> GetSummaryAsync()
    {
        var orders = await _db.Orders.ToListAsync();
        return _globalService.CalculateSummary(orders);
    }
}
 
// Enable validation to catch these at startup!
builder.Host.UseDefaultServiceProvider(options =>
{
    options.ValidateScopes = true;
    options.ValidateOnBuild = true; // Catches captive dependencies!
});

Real-World Service Analysis

Let's apply the decision framework to real services, walking through the reasoning for each lifetime choice.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
// ═══════════════════════════════════════════════════════════════
// SERVICE 1: ProductCatalogService
// ═══════════════════════════════════════════════════════════════
public class ProductCatalogService
{
    private readonly ApplicationDbContext _db;
    
    public ProductCatalogService(ApplicationDbContext db) { _db = db; }
    
    public async Task<List<Product>> SearchAsync(string query)
    {
        return await _db.Products
            .Where(p => p.Name.Contains(query))
            .ToListAsync();
    }
}
 
// Analysis:
// Q1: Per-request state? NO - just performs queries
// Q2: Expensive to create? NO - just stores DbContext reference
// Q3: Thread-safe? IRRELEVANT - depends on scoped DbContext
// Q4: Share globally? NO
// Q5: Share within request? YES - should use same DbContext as other services
// → SCOPED (follows its DbContext dependency)
services.AddScoped<IProductCatalogService, ProductCatalogService>();
 
// ═══════════════════════════════════════════════════════════════
// SERVICE 2: PricingEngine
// ═══════════════════════════════════════════════════════════════
public class PricingEngine
{
    private readonly ImmutableDictionary<string, decimal> _discountRules;
    
    public PricingEngine(IConfiguration config)
    {
        // Loads discount rules at construction (takes 500ms)
        var rules = LoadDiscountRulesFromConfig(config);
        _discountRules = rules.ToImmutableDictionary();
    }
    
    public decimal CalculatePrice(Product product, string customerTier)
    {
        var basePrice = product.Price;
        if (_discountRules.TryGetValue(customerTier, out var discount))
            return basePrice * (1 - discount);
        return basePrice;
    }
}
 
// Analysis:
// Q1: Per-request state? NO - rules are application-global
// Q2: Expensive to create? YES - 500ms initialization
// Q3: Thread-safe? YES - immutable state only, pure function
// Q4: Share globally? YES - same rules for all requests
// → SINGLETON
services.AddSingleton<IPricingEngine, PricingEngine>();
 
// ═══════════════════════════════════════════════════════════════
// SERVICE 3: ShoppingCartService
// ═══════════════════════════════════════════════════════════════
public class ShoppingCartService
{
    private readonly ApplicationDbContext _db;
    private readonly IUserContext _userContext;
    
    public ShoppingCartService(ApplicationDbContext db, IUserContext userContext)
    {
        _db = db;
        _userContext = userContext;
    }
    
    public async Task AddToCartAsync(int productId, int quantity)
    {
        var userId = _userContext.CurrentUserId;
        var cart = await _db.Carts
            .Include(c => c.Items)
            .FirstOrDefaultAsync(c => c.UserId == userId);
        
        cart.Items.Add(new CartItem(productId, quantity));
        await _db.SaveChangesAsync();
    }
}
 
// Analysis:
// Q1: Per-request state? NOT IN SERVICE - but depends on IUserContext which is per-request
// Q2: Expensive? NO
// Q3: Thread-safe? N/A - follows dependencies
// Q4: Share globally? NO - user-specific operations
// Q5: Share within request? YES - should share DbContext
// → SCOPED
services.AddScoped<IShoppingCartService, ShoppingCartService>();
 
// ═══════════════════════════════════════════════════════════════
// SERVICE 4: InvoiceGenerator
// ═══════════════════════════════════════════════════════════════
public class InvoiceGenerator
{
    private readonly PdfDocument _document; // Non-thread-safe library
    private readonly List<LineItem> _items = new();
    
    public InvoiceGenerator()
    {
        _document = new PdfDocument();
    }
    
    public void AddItem(string description, decimal amount)
    {
        _items.Add(new LineItem(description, amount));
    }
    
    public byte[] GeneratePdf()
    {
        // Writes all _items to _document and returns PDF bytes
    }
}
 
// Analysis:
// Q1: Per-request state? YES - accumulates items for ONE invoice
// Q2: Expensive? NO
// Q3: Thread-safe? NO - PdfDocument and List are not thread-safe
// Decision: TRANSIENT - must be fresh for each invoice generation
services.AddTransient<IInvoiceGenerator, InvoiceGenerator>();
 
// ═══════════════════════════════════════════════════════════════
// SERVICE 5: RateLimiter
// ═══════════════════════════════════════════════════════════════
public class RateLimiter
{
    private readonly ConcurrentDictionary<string, SlidingWindow> _windows = new();
    private readonly int _maxRequests;
    private readonly TimeSpan _windowSize;
    
    public RateLimiter(IConfiguration config)
    {
        _maxRequests = config.GetValue<int>("RateLimit:MaxRequests");
        _windowSize = config.GetValue<TimeSpan>("RateLimit:WindowSize");
    }
    
    public bool IsAllowed(string clientId)
    {
        var window = _windows.GetOrAdd(clientId, _ => new SlidingWindow(_windowSize));
        return window.TryAcquire();
    }
}
 
// Analysis:
// Q1: Per-request state? NO - tracks ALL clients across ALL requests
// Q2: Expensive? NO
// Q3: Thread-safe? YES - uses ConcurrentDictionary
// Q4: Share globally? YES - must track requests globally to rate limit
// → SINGLETON
services.AddSingleton<IRateLimiter, RateLimiter>();

Common Lifetime Mistakes and How to Avoid Them

Mistakes That Cause Production Issues

•Making DbContext singleton — Causes connection exhaustion, stale tracking, threading corruption. Always scope DbContext.
•Singleton capturing scoped dependencies — The captive dependency problem. Enable ValidateScopes to catch at startup.
•Using regular Dictionary in singleton — Must use ConcurrentDictionary. Regular collections corrupt under concurrent access.
•Transient for expensive services — Initialization runs on every request. Profile and promote to singleton if safe.
•Scoped services in background workers — No automatic scope in background threads. Must create scope explicitly.
•Singleton storing request-specific data — Current user, tenant ID in singleton fields. Creates cross-request contamination.
•Ignoring IDisposable in transients from root — Transient IDisposable from root container leaks until shutdown.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// 1. Enable scope validation in development
if (builder.Environment.IsDevelopment())
{
    builder.Host.UseDefaultServiceProvider(options =>
    {
        options.ValidateScopes = true;   // Catches captive dependencies
        options.ValidateOnBuild = true;  // Validates entire DI graph at startup
    });
}
 
// 2. Use code analyzers that flag DI issues
// Install: dotnet add package Microsoft.Extensions.DependencyInjection.Analyzers
 
// 3. Add unit tests for lifetime correctness
[Fact]
public void AllSingletons_ShouldNotDependOnScopedServices()
{
    var builder = WebApplication.CreateBuilder();
    ConfigureServices(builder.Services);
    
    using var app = builder.Build();
    
    // Trigger full DI graph construction - will throw if captive dependencies
    app.Services.GetRequiredService<IServiceProviderIsService>();
    
    // No exception = graph is valid
}
 
// 4. Review checklist before registering any service:
//    □ What state does this service hold?
//    □ Does that state vary per-request?
//    □ Is the service thread-safe?
//    □ What are its dependencies' lifetimes?
//    □ Does a longer-lived service depend on it?

Lifetime Guidelines by Architectural Layer

Different architectural layers have characteristic lifetime patterns. Use these as starting points for your decisions:

Typical Lifetimes by Architecture Layer
Layer	Typical Components	Typical Lifetime
Presentation	Controllers, Razor Pages, API Controllers	Transient/Scoped (framework-managed)
Application Services	Use case orchestrators, command handlers	Scoped
Domain Services	Domain logic, business rules	Scoped (often uses repositories)
Infrastructure - Data	Repositories, DbContext, UoW	Scoped
Infrastructure - External	API clients, message publishers	Singleton (with thread-safe design)
Infrastructure - Cross-cutting	Logging, caching, configuration	Singleton
Infrastructure - Per-Operation	File handlers, document generators	Transient

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
public static class ServiceCollectionExtensions
{
    public static IServiceCollection AddApplicationLayer(this IServiceCollection services)
    {
        // Application services: Scoped (orchestrate per-request work)
        services.AddScoped<IOrderApplicationService, OrderApplicationService>();
        services.AddScoped<ICustomerApplicationService, CustomerApplicationService>();
        services.AddScoped<IInventoryApplicationService, InventoryApplicationService>();
        
        return services;
    }
    
    public static IServiceCollection AddDomainLayer(this IServiceCollection services)
    {
        // Domain services: Scoped (often need data access)
        services.AddScoped<IPricingDomainService, PricingDomainService>();
        services.AddScoped<IInventoryAllocationService, InventoryAllocationService>();
        
        return services;
    }
    
    public static IServiceCollection AddInfrastructure(this IServiceCollection services)
    {
        // Data access: Scoped (follows DbContext)
        services.AddScoped<IOrderRepository, OrderRepository>();
        services.AddScoped<ICustomerRepository, CustomerRepository>();
        services.AddScoped<ApplicationDbContext>();
        
        // External APIs: Singleton (connection pooling, thread-safe)
        services.AddSingleton<IPaymentGateway, StripePaymentGateway>();
        services.AddSingleton<IShippingService, FedExShippingService>();
        
        // Cross-cutting: Singleton (stateless or thread-safe)
        services.AddSingleton<ICacheService, RedisCacheService>();
        services.AddSingleton<IEventPublisher, RabbitMqEventPublisher>();
        
        // Per-operation: Transient (fresh state each time)
        services.AddTransient<IPdfGenerator, PdfSharpGenerator>();
        services.AddTransient<IExcelExporter, EPPlusExporter>();
        
        return services;
    }
}
 
// Usage in Program.cs
builder.Services
    .AddApplicationLayer()
    .AddDomainLayer()
    .AddInfrastructure();

Summary: Lifetime Selection Mastery

Selecting the correct lifetime is a systematic process, not guesswork. By analyzing state characteristics, thread safety, creation costs, and dependency relationships, you can confidently choose the right lifetime for any service.

Key Takeaways

•Start with the decision tree — Per-request state? Thread-safe? Expensive? Share globally? Share per request? Each answer narrows options.
•DbContext is always scoped — This is non-negotiable for transaction coherence and thread safety.
•Singletons must be thread-safe — No mutable state, or concurrent collections, or explicit synchronization.
•Respect the compatibility matrix — Singletons cannot safely depend on scoped or transient services.
•Enable scope validation — Catch captive dependencies at startup, not in production.
•Default to scoped when unsure — It's the safe middle ground for most services touching data.
•Transient for per-operation state — Document generators, validation collectors, file processors.

Module Complete:

You now have comprehensive mastery of dependency lifetime management. You understand each lifetime deeply, you know when to apply each, and you can systematically make correct decisions. This skill directly translates to more reliable, efficient, and maintainable applications.

Module Complete

Congratulations! You have mastered dependency lifetime management. You can now confidently select transient, scoped, or singleton lifetime for any service, understanding the implications of each choice. This knowledge is essential for building robust, scalable applications with proper dependency injection.