Advice for ideal setup

We are already using Hangfire for a while now and it’s proven it’s value in keeping our old and new system in sync.
Now we want to take it a step further. Our new application still makes direct DB calls to our old system and it’s slowing down the application. So my plan is to remove this by taking more advantage of Hangfire.

Currently we have a simple setup. 1 server with 1 (default) queue.
In our new setup we can identify 2 types of jobs.

  • Long running
  • Fire-and-Forget

The long running jobs are your typical ETL type jobs. Read some data from the old system and transform it to upsert it into the new. (or the other way around)
The fire-and-forget jobs will be short simple actions that are triggered from our application. For example update customer data in the old system when somebody changes it in the new.

My first idea was to create 2 separate queues (fastlane, slowlane) and assign jobs to the queue depending on the type.
I would also use 2 virtual servers to run these. But I’m not sure what the most ideal setup would be.
Run both queues on both servers or use 1 server for 1 queue.

Is there any recommendation that I can follow? Or does anybody have any experience?
For the record, we are running Hangfire in a Windows Service on 1 physical server for the moment.

Your fire and forget is transactional/unit of work. Fire and forget just means you aren’t waiting for a result, has nothing to do with the the length of time nor complexity of the job. Hangfire is designed for long running processes and is not inherently transactional. I would suggest a messaging system with a unit of work implementation for transactional jobs. Hangfire can have a lot of overhead which may prevent it from scaling to many jobs depending on your job storage (see Using Redis — Hangfire Documentation).

I’ve seen a lot of issues in the forums with keeping queues separate, especially if there is a fail and retry. If you go this route I would suggest setting it so long running is the default queue and “fast” is an explicit queue. It’s better to have some of the fast jobs make their way into the slow lane than the other way around.

How you setup the server isn’t really important, you can always separate them and scale one over the other if the queues start to build up. It is mainly whether you want to keep the code bases separate.

Ok, thanks for the reply. The fire-and-forget jobs can indeed also be long running in some cases.
The distinction is actually more scheduled jobs vs started from my client application.