De Hangfire a RabbitMQ: Eliminando el polling de la base de datos

Hangfire es ideal para equipos pequeños. Añades un paquete NuGet y lo apuntas a tu base de datos. Obtienes un ejecutor de trabajos y un dashboard de forma gratuita. Para un solo servicio, es difícil de superar.

Utilicé Hangfire en SavePosty para gestionar correos electrónicos, webhooks y la obtención de contenido. Cada trabajo funcionaba de la misma manera. Todos realizaban polling en mi base de datos Postgres cada pocos segundos para buscar nuevo trabajo.

Finalmente, lo moví todo a RabbitMQ. Aquí explico por qué lo hice y qué perdí.

Por qué me cambié:

  • La carga del polling escala con el tiempo, no con el trabajo. Cada trabajo de Hangfire consulta tu base de datos mediante un temporizador. Incluso si no hay trabajo, la base de datos permanece ocupada. Este coste crece con el número de trabajos y la frecuencia de polling.
  • Demasiados modelos. Una parte de mi aplicación ya utilizaba RabbitMQ. El resto utilizaba Hangfire. Esto significaba tener dos formas distintas de gestionar el trabajo en segundo plano. Pasar a RabbitMQ unificó todo.
  • Latencia. Un broker envía el trabajo en el momento en que llega. Hangfire espera al siguiente polling.

Las compensaciones:

Hangfire es fácil de configurar. Utiliza tus tablas SQL existentes. Tiene un excelente dashboard integrado.

RabbitMQ requiere gestionar un broker. Utiliza RAM y red en lugar de la CPU de la base de datos. Obtienes un mejor escalado, pero una mayor carga operativa.

Cómo realicé la migración de forma segura:

Mantuve mi lógica de negocio exactamente igual. Construí consumidores ligeros que actúan como una puerta de entrada. El consumidor recibe el mensaje y se lo entrega a la clase de trabajo existente.

Me centré en dos cosas:

  • Paridad de reintentos. Igualé la configuración de reintentos de Hangfire en el consumidor de RabbitMQ para no perder mensajes.
  • Seguridad del esquema. Mantuve las columnas antiguas como anulables (nullable) para no romper la base de datos durante el despliegue.

Qué perdí:

La mayor desventaja es la visibilidad. Hangfire te permite hacer clic en un trabajo fallido y ver exactamente qué sucedió. RabbitMQ te muestra cuántos mensajes hay en una Dead Letter Queue, pero no te ofrece esa misma vista sencilla por cada trabajo. Ahora confío en logs estructurados en lugar de un dashboard.

Mi consejo:

Quédate en Hangfire si:

  • Ejecutas un único servicio.
  • Tienes un equipo pequeño.
  • Necesitas un dashboard sencillo para la depuración.

Pásate a RabbitMQ si:

  • Tienes múltiples servicios.
  • La carga de tu base de datos debido al polling es alta.
  • Quieres utilizar patrones pub/sub.

La decisión depende de tu sistema, no de un solo trabajo.

Fuente: https://dev.to/gabrielleroux/from-hangfire-to-rabbitmq-killing-database-polling-in-a-net-app-4og4

Comunidad de aprendizaje opcional: https://t.me/GyaanSetuAi