What are the service lifetimes in ASP.NET Core, and how do you choose one?

Say it out loud, then check

All three in one payment

One instalment payment at BMW FS, in time order. Each step names the lifetime at work.

The story

1. Before

   .NET Framework had no container built in. A class that needed something built it itself with new inside its constructor. Teams that wanted a container added Autofac, Unity or Ninject, each with its own words for lifetimes.

   LoansController

   LoanRepository

   AuditWriter

   1/8Before ASP.NET Core, nothing built objects for you. A class that needed something used new.The repository needs the database, so it opens its own connection.The audit writer opens another. One request, two connections, so no shared transaction.A common patch back then: one static connection that every class shares.Two requests use it at once. A connection runs one command at a time, so the second throws.The real problem: each class called new itself, so each class decided how long its parts lived.Now the container builds: a class lists its needs in its constructor and gets them.How long each object lives is now one word at registration.

   BackPlayNext
2. Why it had to change

   Lifetimes were scattered across every class that called new, and nobody could see or change them in one place.

3. How it works now

   One word at registration now decides it: AddTransient, AddScoped or AddSingleton.

4. What happens next

   Each request gets a scope. Scoped objects are shared inside it and disposed when it ends; singletons wait in the root provider until the app stops. If you switch the checks on, the container also checks the lifetime rules at start-up.

5. What we gained

   One place to read and change lifetimes. One DbContext per request, so one SaveChanges is one transaction. No hand-written clean-up. And classes you can test by passing fakes into the constructor.

In the lending API

Program.cs runs once at start-up. Each line tells the container what to build and how long to keep it: that is the lifetime.

Only the key lines are shown; Deep walks the whole file.

The code, file by file

Slice 3 of the lending API: all three lifetimes in one Program.cs, then the classes that use them. Each note says why that lifetime was picked.

Which one, and what lives where

Two questions pick the lifetime: what does the object hold, and who should share it? Tap an answer.

What they ask next

The follow-ups interviews really ask. Answer out loud, then tap to check.

• ReportedInside one request, what is the difference between transient and scoped?

  Scoped: every class in the request gets the same object. Transient: every class gets its own. It matters when the object holds state, like a DbContext with unsaved changes: with transient, two repositories cannot save in one transaction.

  Diagram + next questions →Where this was reported
• ReportedHow do you decide which lifetime to use?

  Two questions. Does it hold this request's data? Scoped. Is it shared on purpose or costly to build, and thread-safe? Singleton, if it uses nothing scoped. Otherwise transient. Then I check it never depends on something that lives shorter than itself.

  Next questions, in Deep →Open the chooser →Where this was reported
• What happens if a singleton depends on a scoped service?

  The scoped object is built once and stays inside the singleton for the life of the app. That is a captive dependency. With a DbContext it means a change tracker that only grows, stale reads and, when requests share it, concurrency errors.

  Next questions, in Deep →Walk the broken and fixed code →Closest report: an interviewer asks about pinning a transient to a singleton

Follow-up tree

Answer, then open the next level. That is the order an interviewer digs in.

Reporteda candidate was asked Intervieweran interviewer asks it

• ReportedInside one request, what is the difference between transient and scoped?

  Scoped: every class in the request gets the same object. Transient: every class gets its own. It matters when the object holds state, like a DbContext with unsaved changes: with transient, two repositories cannot save in one transaction.

  LoanRepository

  LedgerRepository

  1/6Recording a payment changes two tables. Two repositories do the work.Scoped: both repositories get the same DbContext.One SaveChanges writes both in one transaction. Both succeed, or both roll back.Transient: each repository gets its own DbContext.Two saves, two transactions. The loan saves. The ledger write fails.The payment shows on the loan with no ledger entry. Nothing rolls it back.

  BackPlayNext

  Where this was reported
  • ReportedI want a new instance every time the service is requested. Which one?

    Transient. Every resolve, and every constructor that asks for it, gets a new object.

    builder.Services.AddTransient<
      IValidator<CreateLoanRequest>,
      CreateLoanRequestValidator>();

    Where this was reported
    • ReportedGive a real scenario where you used transient.

      Typed HTTP clients and validators. AddHttpClient<ICreditBureauClient, FakeCreditBureauClient>() registers the client as transient while IHttpClientFactory pools the connections underneath. Validators keep nothing, so a new one per request is free. I avoid transient for anything that owns a connection itself. Why the factory: new HttpClient() per call runs out of sockets under load, and one static client never sees DNS changes.

      builder.Services.AddHttpClient<
        ICreditBureauClient,
        FakeCreditBureauClient>();

      Where this was reported
  • A console app or background job has no HTTP request. What is a scope there?

    A scope is a box the container opens and closes. ASP.NET Core opens one per request for you. Anywhere else you open it yourself, and use CreateAsyncScope when services dispose asynchronously. The same goes for Program.cs when you migrate or seed: open a scope from app.Services. Resolving ServicingDbContext from app.Services directly throws "Cannot resolve scoped service from root provider" in Development, and in Production quietly keeps one context for the app's life.

    await using var scope =
      scopes.CreateAsyncScope();
    var db = scope.ServiceProvider
      .GetRequiredService<ServicingDbContext>();

• ReportedHow do you decide which lifetime to use?

  Two questions. Does it hold this request's data? Scoped. Is it shared on purpose or costly to build, and thread-safe? Singleton, if it uses nothing scoped. Otherwise transient. Then I check it never depends on something that lives shorter than itself.

  Open the chooser →Where this was reported
  • InterviewerWhy not…Why not register everything as transient to be safe?

    It is not safe. Two repositories in one request would each get their own DbContext, so they cannot share a transaction, and costly objects get rebuilt on every ask. One r/dotnet interviewer admits they once registered everything as transient.

    Where this was reported
  • Is a singleton thread-safe automatically?

    No. The container promises one instance, nothing more. Every request thread calls it at the same time, so its state must be immutable or use thread-safe types.

    • Your singleton keeps rates in a Dictionary. How do you make it safe?

      ConcurrentDictionary or IMemoryCache, or build an immutable copy and swap it in with one assignment. A plain Dictionary written by two threads corrupts itself.

      private readonly
        ConcurrentDictionary<string, decimal>
        _rates = new();

      See the production bug →
  • Who disposes a service, and when?

    The container disposes what it built, if it implements IDisposable or IAsyncDisposable. Transient and scoped objects go when their scope ends; singletons at shutdown. Anything you build with new yourself, you dispose. Two traps: an instance you pass in yourself (AddSingleton(new RateCache())) is never disposed by the container, but one built by a factory lambda is. And a service that is only IAsyncDisposable throws if its scope is disposed synchronously, which is why CreateAsyncScope exists.

    // Built by the container: it disposes it.
    public LoanRepository(ServicingDbContext db)
     
    // Built by you: you dispose it.
    using var db = new ServicingDbContext(o);

    • A disposable transient is resolved from the root provider in a loop. What happens to memory?

      It leaks. The root provider keeps every disposable it builds on a list, to dispose at shutdown, so the garbage collector cannot free any of them. Resolve inside a scope instead.

      See the animation and the fix →
  • One class implements two interfaces, both registered as singleton. How many objects?

    Two: AddSingleton<IA, Impl>() and AddSingleton<IB, Impl>() each build their own. Register the class once and forward the second: AddSingleton<IB>(sp => sp.GetRequiredService<Impl>()).

  • How do you swap a registration in an integration test?

    In WebApplicationFactory, ConfigureTestServices with RemoveAll<T>() then your fake. Watch singletons: every test sharing one factory shares them, so their state leaks between tests.

• Which lifetime does DbContext use, and why?

  Scoped: AddDbContext registers it that way by default. One request is one unit of work, so every repository shares the same context and one SaveChanges. It is not thread-safe, so two requests must never share one.

  • Can you register DbContext as a singleton?

    You can, and you should not. Every request would share one context.

    builder.Services.AddDbContext<
      ServicingDbContext>(o => o.UseSqlServer(cs),
      ServiceLifetime.Singleton); // don't

    • What exactly breaks?

      Three things. Threading: two requests use it at once and EF Core throws. Memory: a DbContext keeps a list of every row it loaded (the change tracker) so SaveChanges can spot edits; a scoped one is thrown away after the request, but a captive one never is, so the list grows with every request. Stale data: when it loads a row it already has, it hands back its old copy, so a rate changed in the database is not seen.

      System.InvalidOperationException: A second operation was started on this context instance before a previous operation completed.

  • What could happen if DbContext is registered as transient?

    Each class gets its own context. Changes made through one are invisible to the other, and there is no shared transaction, so one save can succeed while the other fails. The first follow-up's animation shows a half-saved payment.

    builder.Services.AddDbContext<
      ServicingDbContext>(o => o.UseSqlServer(cs),
      ServiceLifetime.Transient); // don't

    Suggested by an r/dotnet commenter as a sharper question
  • A BackgroundService needs the database, and it is a singleton. What do you do?

    Inject IServiceScopeFactory. Open a scope for each run of the loop, resolve the context from it, and let the scope dispose it. Microsoft's docs show the same pattern.

    while (!ct.IsCancellationRequested)
    {
      await using (var scope =
        _scopes.CreateAsyncScope())
      {
        var db = scope.ServiceProvider
          .GetRequiredService<
            ServicingDbContext>();
        await DispatchAsync(db, ct);
      }   // scope closed before the wait
      await Task.Delay(_every, ct);
    }

    • Why not…Why not inject IServiceProvider everywhere and resolve what you need?

      That is the service locator pattern: asking for things by hand instead of listing them in the constructor. The constructor no longer shows what the class needs, a missing registration fails at run time instead of start-up, and tests must build a container. I resolve by hand only at the edges, like this loop.

    • What is IDbContextFactory, and when would you use it instead?

      A singleton factory that builds a context when you ask. I use it when one scope is the wrong size: Blazor Server, parallel work inside one request, or a singleton that needs short-lived contexts. I own the dispose.

      builder.Services
        .AddDbContextFactory<ServicingDbContext>();
       
      await using var db =
        await _factory.CreateDbContextAsync(ct);

  • What does AddDbContextPool change?

    It reuses context objects across requests and resets them in between; each request still has its own while it runs. So never keep per-request state, such as a tenant or dealer id, in the context's constructor: the next request gets the old value, which leaks one client's data to another.

• What happens if a singleton depends on a scoped service?

  The scoped object is built once and stays inside the singleton for the life of the app. That is a captive dependency. With a DbContext it means a change tracker that only grows, stale reads and, when requests share it, concurrency errors.

  Walk the broken and fixed code →Closest report: an interviewer asks about pinning a transient to a singleton
  • Does it behave the same in Development and Production?

    No. In Development the host turns on ValidateScopes and ValidateOnBuild, so the app fails at start-up. In Production both are off by default, so the app starts and fails later under load. The lending API turns both on everywhere.

    Development:
    $ dotnet run
    Unhandled exception. System.AggregateException: Some services are not able to be constructed ... Cannot consume scoped service 'Lending.Infrastructure.Origination.OriginationDbContext' from singleton 'Lending.Infrastructure.Origination.RateCache'.
    
    Production, checks off, two requests overlap:
    fail: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware[1]
    System.InvalidOperationException: A second operation was started on this context instance before a previous operation completed.
       at Lending.Infrastructure.Origination.RateCache.GetAsync(String product)

    • What do ValidateScopes and ValidateOnBuild do? Would you turn them on in production?

      ValidateScopes throws when a scoped service is resolved from the root or held by a singleton; on its own it fails at resolve time. ValidateOnBuild checks at start-up that every registration can be built, by walking each constructor's needs; it creates nothing and cannot see inside factory lambdas. Together they fail start-up. ValidateOnBuild costs some start-up time, ValidateScopes a little on each resolve, which is why Microsoft leaves them on only in Development. I turn them on everywhere, or at least in a CI test that builds the host as Production.

      builder.Host.UseDefaultServiceProvider(o =>
      {
        o.ValidateScopes = true;
        o.ValidateOnBuild = true;
      });

  • InterviewerHow do you avoid pinning a transient resource to a singleton?

    Three ways. Make the consumer shorter-lived too. Or keep it a singleton and inject a factory (IServiceScopeFactory, IHttpClientFactory) and ask it per call. Or pass the object in as a method argument instead of storing it in a field.

    // The caller passes its own context in;
    // the singleton never stores it.
    public Task<decimal> GetAsync(
      string product, OriginationDbContext db)
      => db.ProductRates
        .Where(r => r.Product == product)
        .Select(r => r.AnnualRate)
        .FirstAsync();

    Where this was reported
  • Scoped depends on transient. Singleton depends on transient. Which is a problem?

    Scoped on transient is fine: the transient lives for the request. Singleton on transient pins the transient for the life of the app. That is harmless if it keeps nothing, and a bug if it holds a connection or a typed HttpClient. ValidateScopes does not catch this one.

    // Both take a transient service.
    AddScoped<LoanService>();   // fine
    AddSingleton<RateCache>();  // pinned

  • Which options interface can a singleton take?

    IOptions<T> is a singleton, read once at start. IOptionsSnapshot<T> is scoped and re-read per request, so a singleton cannot take it (the same scope error). IOptionsMonitor<T> is a singleton with CurrentValue and OnChange: the one a singleton uses for settings reloaded from App Configuration.

Production bugs, and how to tell them

Each one: what you see, why, the fix in code, and the line to say.

• Captive dependency: a singleton holds a DbContext

  $ dotnet run
  Unhandled exception. System.AggregateException: Some services are not able to be constructed (Error while validating the service descriptor 'ServiceType: RateCache Lifetime: Singleton ImplementationType: RateCache': Cannot consume scoped service 'OriginationDbContext' from singleton 'RateCache'.)
     (trimmed)

  Cause

  A singleton RateCache took the scoped OriginationDbContext in its constructor and kept it in a field.

  Fix

  Inject IServiceScopeFactory and open a scope per call, or make RateCache scoped and keep the shared copy in IMemoryCache.

  Program.csBeforeAfter

  Diagram · step 1AddDbContext registers the context as scoped.Show diagram

  Container

  OriginationDbContextregistered: scoped

  1builder.Services.AddDbContext<2 OriginationDbContext>(o =>3 o.UseSqlServer(cs));4builder.Services5 .AddSingleton<RateCache>();

  Program.cs · line 3 · 1 of 2The context is scoped. Why: one request is one unit of work.

  BackNext line

  Say it

  The scoped object was built once and lived as long as the singleton. With a DbContext that meant a growing change tracker, stale reads, and concurrency errors under load. We fixed it with IServiceScopeFactory, and we keep ValidateScopes and ValidateOnBuild on in every environment so it fails at start-up.

• One customer sees another's loans

  No exception. A customer reports seeing someone else's loan list.
  It happens about once in 2,000 requests, only under load.
  Nobody can reproduce it locally.

  Cause

  RequestContext, which holds the caller's id, was registered as a singleton. Two overlapping requests wrote into the same object.

  Fix

  Register it as scoped. Then add a test that two parallel requests for two users each get only their own loans.

  BeforeAfterRequestContextMiddleware.cs

  Diagram · step 1RequestContext holds who is calling. Someone registered it as a singleton: one object for all.Show diagram

  RequestContextsingleton (the bug)

  UserId = (empty)

  1builder.Services.AddSingleton<2 IRequestContext, RequestContext>();

  Before · Program.cs · line 2 · 1 of 1The bug: one RequestContext for every request. It holds per-request data, so it must be scoped.

  BackNext file

  Say it

  A singleton is shared by every request, so any per-request state in it leaks between users. It only shows when requests overlap, which is why tests passed. Per-request data is scoped, always.

• A singleton with a plain Dictionary

  System.InvalidOperationException: Operations that change non-concurrent collections must have exclusive access. A concurrent update was performed on this collection and corrupted its state. The collection's state is no longer correct.
     at System.Collections.Generic.Dictionary`2.TryInsert(...)
     at Lending.Infrastructure.Origination.RateCache.GetAsync(String p)

  Cause

  Two request threads wrote to a plain Dictionary inside a singleton at the same moment.

  Fix

  ConcurrentDictionary or IMemoryCache, or build an immutable copy and swap it in with one assignment.

  BeforeAfter

  Diagram · step 1One RateCache for the whole app. Every request thread uses its one Dictionary.Show diagram

  RateCachesingleton

  Dictionaryplain, not thread-safe

  1private readonly Dictionary<string, decimal>2 _rates = new();3 4public async Task<decimal> GetAsync(string p)5{6 if (_rates.TryGetValue(p, out var r))7 return r;8 r = await LoadAsync(p);9 _rates[p] = r;10 return r;11}

  Before · RateCache.cs · line 2 · 1 of 4A plain Dictionary inside a singleton. Many readers at once are fine, but one writer while anyone else reads or writes is not.

  BackNext line

  Say it

  The container guarantees one instance, not thread safety. Every request thread calls a singleton at once, so its state must be immutable or use thread-safe types. A plain Dictionary written from two threads may throw, silently lose writes, or hang a thread at 100% CPU.

• Two queries at once on one DbContext

  System.InvalidOperationException: A second operation was started on this context instance before a previous operation completed. This is usually caused by different threads concurrently using the same instance of DbContext.

  Cause

  Task.WhenAll ran two queries on the request's single DbContext to save time.

  Fix

  Await them one after the other. If they really must run in parallel, give each its own context from IDbContextFactory.

  BeforeAfter

  Diagram · step 1One request, one scoped context. A context runs one query at a time.Show diagram

  ServicingDbContextscoped: one per request

  idle

  SQL Server

  1public async Task<Statement> StatementAsync(2 Guid id, CancellationToken ct)3{4 var loan = _db.Loans5 .FirstAsync(l => l.Id == id, ct);6 var pays = _db.Payments7 .Where(p => p.LoanId == id)8 .ToListAsync(ct);9 await Task.WhenAll(loan, pays);10 return new(loan.Result, pays.Result);11}

  Before · LoanRepository.cs · line 1 · 1 of 4Called once per request. _db is that request's scoped context: one connection, one query at a time.

  BackNext line

  Say it

  Scoped means one per request, not one per task. A DbContext still does one operation at a time, even inside one request.

• Memory climbs for days, a restart "fixes" it

  No exception. Memory grows a little every hour.
  After a restart it drops, then starts climbing again.

  Cause

  A singleton loop (a hosted service: it runs for the app's whole life) asked the root provider for a disposable transient, once per reminder. The root keeps every disposable it builds until shutdown.

  Fix

  Open a scope per unit of work and resolve inside it. Or, if the gateway client is thread-safe, register it as a singleton and build it once.

  BeforeAfter

  Diagram · step 4Now a singleton loop asks the root provider instead. No scope is open.Show diagram

  SmsGatewayholds a connection

  1public sealed class ReminderSender2 : BackgroundService3{4 private readonly IServiceProvider _sp;5 // constructor and queue left out6 7 protected override async Task ExecuteAsync(8 CancellationToken ct)9 {10 await foreach (var r in11 _queue.ReadAllAsync(ct))12 {13 var sms = _sp.GetRequiredService<14 ISmsGateway>();15 await sms.SendAsync(r, ct);16 }17 }18}

  Before · ReminderSender.cs · line 4 · 1 of 3This is the root provider: a hosted service is built from the root, not from a request's scope.

  BackNext line

  Say it

  The container disposes what it builds when the scope that built it ends. From the root provider, that is shutdown, so a loop that resolves disposables from the root leaks. A memory dump shows thousands of them held by the root provider's dispose list.

Traps

• Don't sayScoped means one per user or per session.SayOne per scope. In a web app the scope is one HTTP request; the same user's next request gets a new one.
• Don't saySingletons are thread-safe.SayA singleton is one object shared by all threads, so I have to make it thread-safe.
• Don't sayTransient is always the safe choice.SayTransient can break a unit of work: two DbContext objects, two transactions. It also rebuilds costly objects.
• Don't sayScoped is only for DbContext.SayScoped is for any per-request state: the DbContext, the current user, a request's unit of work.
• Don't sayA static field is the same as a singleton.SayA static field is a singleton the container cannot see: no test swaps, no dispose, no start-up checks.

Traps

What should you say instead? Tap to check.

• Don't sayScoped means one per user or per session.

  Say instead

  One per scope. In a web app the scope is one HTTP request; the same user's next request gets a new one.

• Don't saySingletons are thread-safe.

  Say instead

  A singleton is one object shared by all threads, so I have to make it thread-safe.

• Don't sayTransient is always the safe choice.

  Say instead

  Transient can break a unit of work: two DbContext objects, two transactions. It also rebuilds costly objects.

• Don't sayScoped is only for DbContext.

  Say instead

  Scoped is for any per-request state: the DbContext, the current user, a request's unit of work.

• Don't sayA static field is the same as a singleton.

  Say instead

  A static field is a singleton the container cannot see: no test swaps, no dispose, no start-up checks.