CommandScheduler 1.0.3

Integrate MediatR with Hangfire

Decoupling CQRS Commands

In a tightly coupled architecture, the application must wait for the database server to respond before it can finish a transaction. This design has the potential to create performance bottlenecks in both synchronous and asynchronous applications. Should the database server slow down due to poor tuning or hardware issues, the application will slow. Should the database stop responding or crash, the application will potentially crash as well.

graph LR
A[Application] -- Tightly coupled application --> B((Database))

By decoupling the database from the application, a loosely coupled architecture is created. In this architecture, Hangfire, as messaging-oriented middleware, acts as an intermediary for the data prior to some action being taken with it in the database. A consumer application picks up the data from the Hangfire server, performing the database action. In this model, should a database need to be taken offline for maintenance, or
should the write workload become too heavy, you can throttle the consumer application or stop it. Until the consumer is able to receive the message, the data will persist.

graph LR  
A[Application]-->B(Hangfire) 
B-->C((Database));  

To schedule your commands, execute them parallel with the retry option and monitor them. Hangfire gives you all these kinds of features but You have to have public method which You have to pass to Hangifre method (for example BackgroundJob.Enqueue). This is a problem – with mediator pattern You cannot pass public method of the handler because You have decoupled it from the invoker. So You need a special way to integrate MediatR with Hangfire without affecting basic assumptions.

I presented the way of processing commands asynchronously using MediatR and Hangfire. With this approach we have:

1. Decoupled invokers and handlers of commands.
2. Scheduling commands mechanism.
3. Invoker and handler of command may be other processes.
4. Command execution monitoring.
5. Command execution retries mechanism.

These benefits are very important during development using an eventual consistency approach. We have more control over commands processing and we can react quickly if a problem will appear.

For this, In HSP.Infrastructure.Toolkits.CommandScheduler we defined 4 classes:

• CommandsScheduler serializes commands and sends them to Hangfire.
• CommandsExecutor responds to Hangfire jobs execution, deserializes commands and sends them to handlers using MediatR.
• MediatorSerializedObject wrapper class for serialized/deserialized commands with additional properties – command type and additional description.
• MediatorExtension extension methods for IMediator

public class MyMController : Controller
{
    private IMediator _mediator;
    
    public MyMicroserviceController(IMediator mediator)
    {
        _mediator = mediator;
    }
    
    [HttpPost]
    public async Task<IActionResult> Post([FromBody] TestCommand testCommand)
    {
     _mediator.Enqueue(testCommand);

      return Ok();
    }
  }

And our commands are scheduled, invoked and monitored by Hangfire.

Download source code

CommandScheduler is available on GitHub. https://github.com/AliBayatGH/CommandScheduler