Services
Technology Web App Development Mobile App Development Windows App Development Database Development UI/UX Development Cloud Development SEO Digital Marketing Guest Posting Content Writing Artificial Intelligence Data Science ERP Development CRM Development CMS Development LMS Development Business Listing Blockchain Technology Startup Promotion AI Tools Integration
Products
Data Converter Cleaner TUC - Unit Converter Import Export Survey Manager Tweet Controller
Developer
Article Blog Forum Interview Beginner News Startup Quiz
Users
Career
Apply Job Internship
Pricing
Login Sign Up Get a Quote

forum

Home Forums How to isolate Hangfire job processing into a separate Background Worker in ASP.NET Core? – MindStick
Ask Question

How to isolate Hangfire job processing into a separate Background Worker in ASP.NET Core?

Manish Sharma 155 17 Sep 2026

Currently, our ASP.NET Core Web API handles both user HTTP requests and heavy Hangfire background job executions. During peak hours, CPU usage spikes heavily, degrading API response times.

Architecture Separation

We want to move the server component (job execution) into a standalone Worker Service project while keeping job creation inside the Web API project.

Web API Enqueue Setup

// Enqueuing job from API endpoint without processing local jobs
app.MapPost("/api/reports", (IBackgroundJobClient jobClient) => 
{
    // Trigger background execution without running processing server locally
    jobClient.Enqueue(() => Console.WriteLine("Processing report..."));
    return Results.Accepted();
});

What is the best practice for sharing job interfaces and contract models between the API client project and the standalone worker service? How do we ensure that the Web API project only enqueues tasks without spawning a Background Processing server instance?

Hangfire hangfireworker-serviceaspnet-corescalabilitymicroservices
Manish Sharma
Ask by Manish Sharma
Updated 17 Oct 2026

1 Answers

Vaibhav Kumar
Vaibhav Kumar 17 Oct 2026
Report Abuse

Keep the web app responsible for accepting requests and enqueueing work, then run a separate worker process to execute the jobs. Both applications connect to the same Hangfire storage, but only the worker starts a Hangfire server.

Configure the web app to enqueue jobs

Register Hangfire storage in the ASP.NET Core app so it can create jobs. Do not call AddHangfireServer here; that would make the web process run jobs too.

using Hangfire;
using Hangfire.SqlServer;

var builder = WebApplication.CreateBuilder(args);

// Read the shared storage connection string used by both applications.
var connectionString = builder.Configuration.GetConnectionString("Hangfire")
    ?? throw new InvalidOperationException("Hangfire connection string is missing.");

// Register Hangfire's client and storage, but do not start a server in this app.
builder.Services.AddHangfire(config => config
    .SetDataCompatibilityLevel(CompatibilityLevel.Version_180)
    .UseSimpleAssemblyNameTypeSerializer()
    .UseRecommendedSerializerSettings()
    .UseSqlServerStorage(connectionString));

// Register the job's dependencies so the web app can enqueue its type.
builder.Services.AddScoped();

var app = builder.Build();

// Enqueue through the client when a request needs background work.
app.MapPost("/reports/{id:guid}", (Guid id, IBackgroundJobClient jobs) =>
{
    jobs.Enqueue<GenerateReportJob>(job => job.RunAsync(id));
    return Results.Accepted();
});

app.Run();

Run the server in a Worker Service

Create a separate Worker Service project and reference the assembly containing the job type. Configure it with the same storage settings and register the job's dependencies. The worker's queues must include any queues assigned to the jobs it should process.

using Hangfire;
using Hangfire.SqlServer;

var builder = Host.CreateApplicationBuilder(args);

// Use the same Hangfire storage as the web app.
var connectionString = builder.Configuration.GetConnectionString("Hangfire")
    ?? throw new InvalidOperationException("Hangfire connection string is missing.");

builder.Services.AddHangfire(config => config
    .SetDataCompatibilityLevel(CompatibilityLevel.Version_180)
    .UseSimpleAssemblyNameTypeSerializer()
    .UseRecommendedSerializerSettings()
    .UseSqlServerStorage(connectionString));

// Register dependencies used when Hangfire activates job classes.
builder.Services.AddScoped<IReportService, ReportService>();

// Start a Hangfire server in this process and listen on the required queues.
builder.Services.AddHangfireServer(options =>
{
    options.Queues = new[] { "reports", "default" };
});

await builder.Build().RunAsync();

The job class can live in a shared application project referenced by both apps. Hangfire creates it in the worker, so its dependencies need to be registered there. For example, put [Queue("reports")] on the job class or method if it should be handled by the reports queue:

using Hangfire;

[Queue("reports")]
public sealed class GenerateReportJob
{
    private readonly IReportService _reportService;

    public GenerateReportJob(IReportService reportService)
    {
        _reportService = reportService;
    }

    // Hangfire invokes this public method when the queued job runs.
    public Task RunAsync(Guid reportId)
    {
        return _reportService.GenerateAsync(reportId);
    }
}

Keep the job assembly and method signatures compatible between deployments: Hangfire stores job details in storage and the worker must be able to resolve them. You can scale processing by running more worker instances against the same storage. If you use recurring jobs, register their schedules in one deliberate place rather than accidentally registering them from every web and worker instance.

MindStick Training
Markdown for AI

A clean, structured version of this page for AI assistants and LLMs.

Open .md