Van Hangfire naar RabbitMQ: Stop met database polling

Hangfire is geweldig voor kleine teams. Je voegt een NuGet-package toe en wijst deze naar je database. Je krijgt gratis een job runner en een dashboard. Voor één enkele service is het moeilijk te verslaan.

Ik gebruikte Hangfire voor SavePosty om e-mails, webhooks en het ophalen van content af te handelen. Elke job werkte op dezelfde manier. Ze controleerden allemaal om de paar seconden mijn Postgres-database om te kijken of er nieuw werk was.

Uiteindelijk heb ik alles verplaatst naar RabbitMQ. Hier lees je waarom ik dat deed en wat ik daarbij heb verloren.

Waarom ik ben overgestapt:

  • De polling-belasting schaalt mee met de tijd, niet met de hoeveelheid werk. Elke Hangfire-job raakt je database via een timer. Zelfs als er geen werk is, blijft de database bezig. Deze kosten groeien naarmate het aantal jobs en de poll-frequentie toenemen.
  • Te veel modellen. Een deel van mijn app gebruikte al RabbitMQ. De rest gebruikte Hangfire. Dit betekende twee verschillende manieren om achtergrondtaken te beheren. De overstap naar RabbitMQ bracht alles samen.
  • Latency. Een broker pusht werk op het moment dat het binnenkomt. Hangfire wacht op de volgende poll.

De afwegingen:

Hangfire is eenvoudig op te zetten. Het maakt gebruik van je bestaande SQL-tabellen. Het heeft een geweldig ingebouwd dashboard.

RabbitMQ vereist het beheren van een broker. Het gebruikt RAM en netwerk in plaats van de CPU van de database. Je krijgt betere schaalbaarheid, maar meer operationele overhead.

Hoe ik veilig ben gemigreerd:

Ik heb mijn businesslogica exact hetzelfde gehouden. Ik heb lichtgewicht consumers gebouwd die fungeren als een voordeur. De consumer ontvangt het bericht en geeft het door aan de bestaande job-class.

Ik heb me op twee dingen gericht:

  • Retry-pariteit. Ik heb de Hangfire-retry-instellingen nagebootst in de RabbitMQ-consumer, zodat ik geen berichten verloor.
  • Schema-veiligheid.