A singleton BackgroundService needs to process jobs using a scoped DbContext. How should it create and own scopes, especially when several jobs run concurrently?

Create DI scopes for background and parallel work

Creates and disposes explicit service scopes for hosted, queued, and parallel work without sharing scoped dependencies across operations.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I inject IServiceScopeFactory into the hosted service and create a new scope for each job or coherent unit of work. I resolve the scoped handler or DbContext from that scope, await the work, and dispose the scope afterward, using an async scope when dependencies support asynchronous disposal. I do not resolve a scoped service once and store it on the singleton. The stopping token flows into both queue waits and the scoped operation.

Full answer below

Practice focus

IServiceScopeFactory, request-independent scopes, DbContext ownership, concurrency isolation, async disposal, cancellation, and queued work boundaries.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Hosted services are singletons and do not receive an HTTP request scope. Each independent unit of work needs an explicit lifetime boundary for its scoped dependencies.
I inject IServiceScopeFactory into the hosted service and create a new scope for each job or coherent unit of work. I resolve the scoped handler or DbContext from that scope, await the work, and dispose the scope afterward, using an async scope when dependencies support asynchronous disposal. I do not resolve a scoped service once and store it on the singleton. The stopping token flows into both queue waits and the scoped operation.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
If several jobs run concurrently, each job gets its own scope and therefore its own scoped dependencies. Sharing one across parallel jobs is unsafe because it is not thread-safe and its change tracker mixes unrelated units of work. I place the business operation in a scoped handler so the singleton coordinator only owns scheduling, concurrency limits, and shutdown behavior. Fire-and-forget work started from a request must carry durable data, not a captured request scope that is disposed after the response.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Injecting DbContext directly into a singleton hosted service.
Creating one scope and sharing its services across parallel jobs.
Starting request fire-and-forget work that captures HttpContext or scoped dependencies.
Creating scopes without disposing them on cancellation and failure paths.

A singleton BackgroundService needs to process jobs using a scoped DbContext. How should it create and own scopes, especially when several jobs run concurrently?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement